I wondering why the AppDelegate class in Xamarin.iOS is an partial class? Because I cannot find a second part to it and when I remove the "partial" keyword, the app still works?
So why Xamarin still generates this class as partial class?
The partial class here is the same reason partial classes are cool everywhere...so that code generators can maintain the automated part of the class while you can write a separate file to maintain your customizations.
Having said that, most of the doc I've seen regarding AppDelegate just has you writing straight into the gen'd code. Total speculation on my part, but I suppose the good folks at Xamarin had expected to make it something that got rebuilt over and over, but changed their minds and never implemented it that way. Problem is...now that it's partial...it'll probably stay partial...to not break developer expectations.
It's probably still good form to write your customizations in a separate file when you see gen'd partial classes. Who knows; some infrastructure piece you use in the future may take advantage of the partial class, and register it's components in its own partial class file.
Related
If we omit visibility modifiers(let's say all methods are public), is there any common convension to put new methods in class? I mean if I put them on bottom it's logically correct, because methods are sorted by date. If I put them on top, it's easy to see and compare what methods are added if the class is very long.
Just depends on what you and your team are comfortable with. I usually have method at the top of my class followed by fields. If there are many method that do different thing you are better off organizing them in a new class. Now without seeing any code I'm simply guessing.
No, I don't think there is.
As Kalagen said it's up to you and your team to decide it.
I would keep any methods that share similar functionality together and keep the class definition short.
The short answer in my opinion is no. Coding style might vary depending on the language you are using and the team you are working with. In addition you might have your own preference as well. I tend to add new methods close to methods that are related to it (e.g. if method1 calls method2 then method1 is above method2). Then it is relatively easy to find the method that's being called. On the other hand, most IDEs can find the method with a mouse click.
If you're using version control, you can easily see what methods were added and in which order, so sorting by date is not needed.
And as others have mentioned, keep the class small. Take a look at the Single responsibility principle. If the methods you are adding are not related to the responsibility of the class, extract them and create a new class.
I'm using the Magnolia Spring Integration (Blossom) for my web app and I definitely don't understand how (if it's even possible) to share a unique area between two pages.
This is how I've worked so far :
I have three templates main-template, template-1 and template-2.
template-1 and template-2 both redirect to main-template by redefining their own "body" areas.
In the class of template-1 I have three areas : content-area, area-1 and area-2
In the script of template-1 I include the three areas with the following directives : [#cms.area name="content-area"/], [#cms.area name="area-1"/] and [#cms.area name="area-2"/]
The same areas are defined in the template-2 class and script
What I want is to share, lets say, area-1 between template-1 and template-2. The problem is that by redefining them in each class they are considered like different areas...
Through my tests and the magnolia documentation, what I understand is that an area can only be defined within a template class so it can be accessed in the script of this template and only the areas defined directly in the template class associated with the page will be process/rendered.
No matter what I try, as long as the areas are not defined in the page's template class they cannot be accessed and therefore included pages don't have their areas rendered.
Does anyone have a clue in how I can "include" or process "areas" from other templates in another one ? Or am I doing it all wrong ?
Thank you for your time.
regards.
I know this is an old question, but it is still a valid question, so let me answer it:
As far as I know areas can inherit from other areas (normal Java class inheritance using "extends ..."). As far as I know this wasn't available in 2013 yet, but it is now. I know this because I filed this as a feature request once and it was marked as solved at some point, and I think I also successfully used it once (don't remember clearly).
If for some reason it's still not possible to extend areas from super classes, then you could still use conventional tools like putting the logic to a helper class and making the actual areas very slim (that is just calls into the shared helper class). And the actual template (.jsp or .ftl file) can be shared anyway.
I've looked through the other questions and am still struggling so if anybody could take the time to look at this, it would be much appreciated :).
I currently have my app working fine but I've been reading and have decided it doesn't fit the MVC design pattern. I am still learning lots about design and would like to edit it so that it is more sound.
I think I know what should go in to my model class, and I think that it should be instantiated in the app delegate. My questions are: why in that location? Is lazy instantiation the best/correct way to do this? And finally, once initiated, do I use a property to access the class or do you use special methods?
Sorry for the overload; I am also trying to get my reputation up enough to vote on other questions! :)
It's really hard to answer a general question like this, since there are so many ways one could implement any particular project. In general, I don't think that instantiating a model class in your app delegate is necessarily the way to go. Since a controller class mediates between the model and the view, it's often better to instantiate your model in a controller class -- for instance, I have a program that keeps track of the plants in my garden, and my controller class is a subclass of NSArrayController. It seems to make sense to create new plant objects in the controller and then just add them to its arrangedObjects. I try to have as few connections (via properties or ivars) between classes as I can, the thought being that each class should take care of its own business as much as possible. Often, you don't need to have a reference to the class, because you are calling class methods to create new objects, and then those objects can access any instance methods of that class without any explicit reference to the class.
I'm working on a joomla component that includes building a schedule. On any given day it needs to look at a set of rules (day of the week, date of the year, type of event) and return all of the possible start times. It would make sense to have a class that calculates these things, but I'm not sure it fits in the model or controller (and certainly not view) categories. Am I supposed to create a com_myproject/lib (or similar name) and have joomla auto-load the classes?
I'm new to joomla and started with the framework/project provided at http://docs.joomla.org/Building_Joomla_Extensions_with_Apache_Ant.
You should create a helper class. Have a look here for an example, albeit it is for a module, but the same concept applies.
You might want to start off with Developing a Model-View-Controller Component - Part 1 tutorial and work your way through that by hand. Using Apache Ant to learn how write an extension is like taking a canon to shoot fish in the barrel. It can be done but probably not the best way of doing it.
The Joomla! MVC pattern is very peculiar and difficult to understand. I don't quite understand it myself. I was advised on the developer email list to look at how other components are put together. Guess what? All the other developers do it differently, with some of the bigger components looking like spaghetti code in their organization.
The bulk of your component code should be in the controller, either as part of the controller class or a separate class file that's imported in. You don't need a separate library directory unless you're working on a big component with multiple class files. This Joomla! thread might be applicable.
So thanks to the Visualization and Modeling Feature Pack , I can build a uml model diagram and generate a bunch of classes.
But what now? Presumably, my developers will add code to those classes. Useful code, valuable code, and as the templates themselves indicate:
// Changes to this file will be lost if the code is regenerated.
So what is the best solution here? Can I make the modeling project reflect changes to the actual classes? Should I generate partial classes? Modify the default templates to read class files and not auto-generate anything that has been modified? Should I tell developers not to edit model files under pain of....well, pain?
Thanks for the tips.
As far as I know, this is really the key reason for partial classes in the first place. The custom code goes in one file, the auto-generated in another.
You could also create classes derived from the generated ones, and put any changes in there. I also agree with above poster that partial classes could be the way to go.
Although the tools generate basic skeleton classes out of the box, that's really just a starting point. You can easily adapt the generator templates to create your own stuff. Different people want to generate different code from the classes - some even generate XML or SQL. And yep, in C#, partial classes are good to generate, so's to keep the hand-written code separate from the generated bits.
It's good to put lots of extension points in the generated code, where you fill in the details by hand code.
Another neat idea is "double derived": from each UML class, generate a base class and a derived class. The derived one has only constructors. The base class has any methods you generate. So your hand code can easily override generated methods where you need that.
There are several options in the tool and recommending what is best is hard without knowing your scenario. Partial classes are great for some, but not all applications. If you want your UML class to generate a partial class, you can set it's C# stereotype's property to "Partial" and it will do so, and custom code can then be added in a partial class that won't be overwritten. If you want to prevent code from being overwritten, you can do this by setting the overwrite property to False on the template binding that corresponds to the package you are working on. This lets you set your extension code to be in a package that is not overwritten, while your model mastered code is overwritten with the latest model changes. Finally, if you want your code to be the master for your model so it always reflects the latest code, then you can reverse engineer your code by using the architecture explorer to select your classes and then dragging them in to a UML diagram. So for a given gesture, either the model is the master or the code is the master. In this version, we did not implement automated merge capabilities between the two.