I did something a little bit nasty today.
All of our view controllers inherit from two different parent view controllers, let's say XXXViewController and YYYViewController. XXXViewController in turn inherits from TrackedUIViewController, which is a class provided in the Google Analytics SDK so all your view controllers can inherit from it and easily track them.
YYYViewController however, inherits from a different type of view controller. Ah, and it's an open sourced piece of code that I really don't want to change.
What's the problem here? We cannot track any of the YYYViewController children because we can't access the methods provided in TrackedViewController, since they are private.
I don't want to modify the source provided in the Google Analytics SDK. So what did I do? Create a category that exposes those methods, just to avoid the compilation error.
The obvious downside to this is that the GA source code changes it may break, but it will be fairly easy to detect.
I was wondering what other problems I could be facing by doing this, and if you guys can think of a better approach.
Thank you
You can go up in the inheritance chain of YYYViewController, see in turn what class it inherits from. If it's UIViewController, simply change that particular superclass to TrackedUIViewController in the source and you're fine to go.
Example for better understanding: suppose YYYViewController inherits from ZZZViewController, which in turn inherits from UIViewController. Now you can change the superclass of ZZZViewController from UIViewController to TrackedUIViewController - since TrackedUIViewController inherits from UIViewController, no functionality will be lost, but magically your whole YYYViewController class will become trackable.
Hope this helps :-)
You already mentioned the biggest risk of using undocumented APIs: Changes to the API are beyond your control and may break your logic, for example if methods are removed/renamed, or their behavior stops matching your expectations.
From the purely technical point of view, I can see no further problems, since in Objective-C all methods are public. As long as they continue to exist, you may continue to call them.
I would say the root problem is excessive subclassing. Keep view controller hierarchies shallow. Use composition instead of subclassing. If you must subclass ensure that functionality that a class provides can be turned on & off by it's subclasses.
Related
I'm working on a game (in Unity3D) which consists of a dozen menus and no real 2d/3d game world. From a programmer's perspective it is just a bunch of buttons, labels and images.
To not have everything inside of one big menu class, I decided to split the code in parts for every menu. The result is that I've got a dozen classes which themselves have all the references to their gameobjects and e.g. the button methods.
My problem is that almost everything in my project is static by now, because these menus do not get instantiated multiple times and I have to access variables and methods from one menu with the script of another menu.
Thus my question is what the best practice would be for this situation. I've got a couple of ideas, how I could do it, but unfortunately I didn't get to learn what to do in such a situation.
So if you straight up want to suggest something, feel free to do so. :)
My ideas:
1) Make a controller which has static instances of all menus. A button-method in class 'A' could then call Controller.B.x. This does work, but I dislike putting "Controller" everywhere so often, because most classes access methods and variables from other classes so often, that it's just ugly.
2) Make these menus all be singletons. Afaik are singletons "ok" for something like this, but aren't they just shifting the static instance to their own class instead of one controller? When I switched from option 1) to this with one class, basically Controller.A.x became A.instance.x, where "instance" is the static instance of the class inside the class.
3) Keeping everything the way it is, having variables and method being static whenever I need to access them statically from another class, otherwise make them private.
The game is probably not a "bunch of buttons, labels and images".
I suggest to forget about the menus for a second, focus on the model of your game, create classes strictly for that. You don't put things like "how much of a currency does the player have" in any menu, it should exist in a Player class or similar (the model).
Once you can manipulate your model from a single test controller class, and simply log the results in debug console, you're ready to do the same with menus.
After that, you can much easily create user interfaces to read /display (creating labels and images on the fly) and write (hook button events into) the model beneath. These UI classes will probably have so much in common after that.
You can use UnityEvent class for communication between UI and model, they are nicely shown in the Inspector (the same events used in UI Events and Event Triggers).
Fore more general info, Google on some design patterns like MVC, MVP, MVVM, or VIPER.
My recommendation is to strongly consider why you have statics. I understand your reasoning that they are singletons but I don't think that is a good enough reason.
I hope you are using the Unity GUI features properly.
I would just write a base "Menu" component. Then you can add references into the sub classes. For example.
You have a "StartMenu" class derived from "Menu" which is derived from "MonoBehavior". In "StartMenu" you write a method "ShowCharacterCreationMenu()". Then add a button component and hook the method up to that button press. StartMenu will have to have a reference to Character menu. This is the classical OOP approach.
I would do this a little differently though. Unity's strength lies in component based design so I would lean towards that. I would probably create a "Transition" component class that listens for a button press. When that button is pressed it goes to the next menu.
Hope that makes some sense.
so I'm having a lot of classes that use the UIBinder to make the layout. Each one of those classes has a lot of added features in it though, so it's starting to get a little bit cluttered. My idea was to make a GUI class, where I will initialize the UiFields, and to make a class extend that one, and handle all the events in the subclass.
My problem is, the ClickHandlers are not working anymore. Anyone knows why?
Also is it bad practice to do it this way?
You probably have to implement HasHandlers interface and make sure you GUI extends composite
I am new in iphone development and i needed a array which i use to access in different class so my senior told me that you should declare in App delegate and access it another class in which it require, so i wrote line for that
MyAppAppDelegate * appObject =
(MyAppAppDelegate*)[[UIApplication sharedApplication]delegate];
I done my task successfully but i couldn't get it 100%. Someone tell that why we use this and in what exactly situation in which we've to use this?
AppDelegate is loaded first when you run your application as it contains window. So, the variable and objects you want to access throughout your project is declared in AppDelegate. You just have to create an instance and you can access all the objects in AppDelegate.
ApplicationDelegate can be useful as a singleton class but you have to use it with discretion - and there are varying opinions on this - but if you have a few global type properties or methods you want to recall from various other classes, and I emphasize few, then ApplicationDelegate may be a nice place to add these.
And yes, it is bad design - but you can get away with it if you are prudent and as #Sedate Alien mentions, take a look at dependency injection.
The purpose of ApplicationDelegate, by the way, is mainly to handle events like loading your application, when you return to home screen, when you come back from home screen, etc.
Basically I have a load of classes which are all subviews of UIView.
The app is a (sort of) slideshow application. I want to be able to make lists of potential "routes" that the slides could take in plists.
As such I may have 100s of classes and I don't want to have to include all of them in the potential that I may use one of them once.
So is there a way around this? Can I instantiate a class without including it somehow?
Or am I going to have to include every potential class I'm going to use?
Is there a "global include" like include all... clutching at straws here. :p
Thanks
Tom
Why would you have hundreds of classes? It sounds like you have roughly one custom class, which would represent a slide.
Your comment on the question helps. Consider separating the slide from its content. You could have a single slide class which provides the functionality common to all slides, including the ability to manage one or more content objects. Then you'd create a bunch of different content classes: spreadsheet, animatable graph, checklist, whatever. A slide would look at its data to figure out which content class to instantiate.
If you have a common base class for all your content classes, the slide class only needs to know about the base class. The content base class could act as the manager for all the content classes. You could give it a factory method like -contentForData:(NSData*)data that returns an appropriate content object for the given data. The slide class doesn't need to know about anything more than the content base class then, so this sort of accomplishes your goal of instantiating your content classes without having to include all their headers in your slide class. The content base class would, of course, still have to know about all the content classes.
It gets a little tricky with the base class needing to know about its subclasses but the subclasses being derived from the base class. I think you can get around this by using a forward #class declaration in the content subclasses.
If you're using the class, you must know what set of messages it responds to. Factor out that information into either a common superclass or a protocol, and then you only need to use that.
Can I instantiate a class without including it somehow?
I guess this is not possible because compiler should definitely see class definition in the current scope before using a variable of class type.
IF I understand your question correctly, you want a single place to put your #include directives so that every class in your project has access to them. You can do this in the ProjectName_Prefix.pch file. Any #include or #import statements there will be included in every source code file.
With MVP, you normally bind the View (UI) with the Presenter in the Presenter. However with the latest version of GWT, especially with UIBinding, you can do the following in the View:
#UiHandler("loginButton")
void onAboutClicked(ClickEvent event)
{
// my login code
}
Which basically exchanges a lot of anonymous inner class code for some quick annotation code. Very nice!! The problem is that this code is in the view and not the presenter...
So I thought maybe:
#UiHandler("loginButton")
void onAboutClicked(ClickEvent event)
{
myPresenter.onAboutClicked(...);
}
But there are several problems with this approach. The most important, you blur the lines between View and Presenter. Who does which binding, in some cases it's the View, in others it's the presenter (binding to events not in your current view but that need to be attached - for example a system wide update event).
You still get the benefit of being able to unit test your presenter, but at what cost. The responsibilities are messy now. For example the binding is sometimes in the View and others times in the Presenter level. I can see the code falling into all kinds of chaos with time.
I also thought of extending the Presenter to the View, so that you could do this in the View. The problem here is that you lose the Presenter's ability to run standard unit tests! That's a major issue. That and the lines again become blurred.
So my question, does anyone have a good method of taking advantage of the annotation from UIBinding within the MVP pattern without blurring the lines and losing the advantages of the MVP pattern?
I tend to use the #UiHandler approach only when the Handler does view-specific stuff, like adding style names, etc. For other purposes (adding validation, etc), I stick with the old approach of adding the appropriate Handlers in the Presenter.
I'd recommend reading through one of the many threads on GWT Google Group about MVP and UiBinder, such as this one.
To be honest I don't use the #UiHandler annotation much, because as you said, it starts to muddy the lines between the View and the Presenter. It's totally fine to use, and a great shortcut if you don't particularly care about sticking to the pattern, though.
The presenter.onAboutClicked() route is definitely an option, but then you might as well define the handler in the presenter in the first place.
or if you are looking for a real implementation on how to make it work check out this blog post, I have to say that up until I found it everything else was still noise in my learning.
gwt 2.0.x is a great improvement on gwt 1.x but I still believe google has some way to go with their documentation and guidance since as we have seen with uibinder and mvp, it leaves a lot to the imagination on how to make things work.
hope the link shades a little bit more light on what u need.
If using the MVP pattern, your SomeView interface should have an inner Presenter interface defined which in turn in implemented by your presenter (Activity class). So inside the view do the following:
interface SomeView extends IsWidget
public interface Presenter{
...all the methods
public void doSomeAction(SomeView view);
}
...view methods
}
now in the SomeViewImpl class, attach a handler
#UiHandler("some_button")
void onClickSomeButton(ClickEvent e){
// call the presenter method (you have access to it in the ViewImpl class
presenter.doSomeAction(this);
}
It looks a bit long, but the pattern works great.
It's often useful for the view to delegate some of its actions to the presenter using a pattern sometimes referred to as a "supervising controller".
This has also been advocated by Google as a good way to benefit from the nice #UiHandler annotation at your disposal when you use !UiBinder. The main difference with the original presenter pattern is that the view keeps a link back to the presenter in order to invoke some of its methods, instead of the presenter registering callbacks towards the view.
https://github.com/ArcBees/GWTP/wiki/UiHandlers