I would like to use the accelerometer in a tab app. All three tabs would access the current x,y,z and change an mage based on that data. My problem is where does the initialization of the accelerometer go so that all three tabs can update based on the data? The update only needs to happen when you are in the current tab.
I can only get this to 'work' if I initialize 3 accelerometers which is not correct. Would the data go in my appdelegate and the code to change the images in each nibs view controller?
Try to avoid putting code into appdelegate. Try using appdelegate only to handle basic stuff.
I would recomend you to implement a Singleton-Class for your Accelerometer Data.
Singletons are a very basic design pattern, that come in handy especiall in the environment of mobile devices (fewer ressources than a pc)
you can read about the singleton Pattern here: Wikipedia: Singleton Pattern
also there is a very easy way to synthesize a singelton class in your project
include the follwing file into your project syntesizesingleton.h
and within your accelerometer class put the following
#implementation yourAccelerometerClass
SYNTHESIZE_SINGLETON_FOR_CLASS(yourAccelerometerClass)
afterwards within your view controllers (or wherever) you can acces the singleton-accelerometer class by dong things similar to the following:
[[yourAccelerometerClass sharedyourAccelerometerClass] yourMethod];
hope that helps.
sam
Related
I have a view that is to be shown from different screens in my app. I dont want to allocate and initialize the view from each screen. I thought this could be done using two approaches:
1) Initialize the view in App Delegate and access the same from all the screens. (Note: I dont want add the view on window because my app only supports landscape orientation and this will result in lot of spaghetti code to manage the view orientation.)
2) Make the view singleton instead
Now, there has been a lot debate on whether the Singleton pattern in general is good or bad. Also, I know that using singletons for view controllers is considered as bad idea .
Is there any better approach to achieve this??
Using singletons is not a bad idea, it's actually a solid pattern that allows storage of fast accessible data throughout the application lifecycle. NSUserDefaults, NSFileManager, NSNotificationCenter and many other Apple default classes use singleton pattern. If your view takes up too much memory (e.g. it has a lot of heavy graphical assets on it), then you should have a class that creates that view each time you call it and loads it into memory for a period of time that the view is used in. If your view is light weight, you should create it statically and keep it alive throughout the entire App's lifecycle using singleton class.
Using a singleton or using a property of your app delegate are equivalent ways of accomplishing the same thing. One can also use a common structure passed to all of the "interested parties".
Which you choose is up to you -- the "ideal" choice depends on the circumstances.
Do be wary, however, of ending up with dozens or hundreds of singletons -- this usually indicates that your design is not very well thought out.
Singletons are modern global variables so I try to avoid them unless absolutely necessary. The use of Apple's low memory globals caused all sorts of problems when porting to Carbon.
If you are maintaining libraries beware that there will be an instance of the singleton for each library so you need to be careful who is accessing them. I ran into this with the Loki singleton implementation (C++), although it would make sense that an Objective-C singleton would have the same issue.
I have a view that is to be shown from different screens in my app. I
dont want to allocate and initialize the view from each screen.
Why don't you want to create the view as you need it? Views use a lot of memory:
a half-screen view (240*320) on a non-retina iPhone requires 300KB just for the pixels.
the same view on a retina display requires 1.2MB
For that reason alone, allocating your common view only when you actually need it seems like a very good idea. There's nothing to be gained by hanging onto the view when it's not being displayed.
I'm new to iphone development. There's a lot of books on this topic available. But most of the beginner's guides are mostly concerned with Interface Builder usage and lack the information about existing built in XCode code templates or something that could help me in understanding MVC implementation in code. I found that it is possible to write working iOS program without ViewController at all. Well, it seems to me like that after working with the sample code called ViewTransitions.
So, the question is - why is that possible to avoid ViewController implementation in a program that has an interface with a button? If the answer is going to be too long, could you please recommend kind of tutorial or manual covering this topic.
Thanks in advance.
#user697562's answer is essentially correct: in the case of ViewTransitions, the role of the controller is played by the app delegate. The app does next to nothing -- it just switches betweeen two views to demonstrate several possible transition effects -- so a UIViewController isn't really needed there.
Notice that there's also nothing in ViewTransitions that you could really call a model object. If you're looking for a strong example of MVC, ViewTransitions isn't the best project to look at. Other sample projects, such as TheElements, give a better demonstration of MVC in action.
There is a concept called delegation. A concept which helps maintain MVC. It helps to keep the model separate from controllers. For eg: - UITableView/UICollectionView , which knows how to display the data and other ui stuff.
But it does not know which cell to display or what data to display at a particular index. And this is where delegation and the delegate object comes into place. UICollectionView handles all the view part whereas all the non view part is handled by the delgate object, which gives the required data for the view. This way a delegate(usually a separate view controller) acts as a data source and UICollectionView as a ui renderer.
in ViewTransitions, there IS an App Delegate, which is kind of your sole "controller". Even ViewTransitions has:
transition.delegate = self;
IOS is a bit different from some frameworks in that you aren't as "in control" of what is going on. It often uses a delegation model where you set your code as the delegate, but it (IOS) is in control. Still, you can write in MVC style, it's just your "C" isn't fully in charge.
I am learning tons on this thing. Reading also, but this is awesome!
Ok.. so long story sort I hope. I'm making a data class to pump out some instances of people that have various attributes. I would like my view controllers to be able to access them (through properties of course.. I think) to manipulate their data.
Where in an iphone app would be the best place to do this, and how would you write the code to message to this object. My current setup would be to have a navigation controller with a firstlevelviewcontroller that created a few secondlevelviewcontroller children instances that would do things like pickers for date of birth, and height, weight, etc.
Could the Navigation Controller make these model objects? Should application delegate? Lets say application delegate does. If so, then how would I put references to these objects from my first and second level view controllers?
Awesome!
**Update for the new millenium. **
I'm reading on core data structures, and though they are awesome, they are above and beyond what I need for this project. what I need is simple, I think..
I want one class that is a data class with a few variables that I can manipulate. I want to manipulate these from two view controllers. I might want more than one data instance, so I don't want a singleton data object. I don't need a persistent store of data.
I would like to know how to step by step have this data class instantiated.. should it be in app delegate? can i do it somewhere else? I dont want it a child of one of the view controllers.. How would I do that? then, how would I reference it from the view controllers and manipulate data (I'm pretty sure through properties but I can't figure out how to reference the instances to make this happen).
CHeers! thanks for the help!
Lots of questions that fringe on conjunction of various best practices.
First, the NSManagedObjectContext (if instantiated in the application delegate) can be shared in any number of ways. You can push it on through as you load your controllers or, something I've been more want to do (and will gladly argue the merits), you can hand it off to a Singleton that any controller has access to.
Depending on the model graph and how your UI maps to the data objects (you didn't say), keep in mind being memory friendly. I defer creating the NSFetchRequests until there is a controller that needs the data (CRUD).
If you want to edit your question or add comments that may provide more clarity... the answer may change
Frank
This is Cocoa Touch (et al), iPhone, XCode only.
After completing my first commercial iPhone app, I'm struggling a bit to find a way to start and expand an app from scratch which gives the most linear development (i.e., the least scrapping, re-write or re-organization of code, classes and resources) as app specs change and I learn more (mostly about what Cocoa Touch and other classes and components are designed to be capable of and the limitation of their customization).
So. File, New Project. Blank window based app? Create the controllers I need, with .xib if necessary, so I can localize them and do changes requested by the customer in IB? And then always subclass each class except those extremely unlikely to be customized? (I mean framework classes such as UIButton, CLLocation etc here.)
The question is a generic 'approach' type question, so I'll be happy to listen to handy dev practices you've found paid off. Do you have any tips for which 're-usable components' you've found have become very useful in subsequent projects?
Clients often describe programs in terms of 'first, this screen appears, and then you can click this button and on the new screen you can select... (and so on)' terms. Are there any good guides to go from there to vital early-stage app construction choices, i.e. 'functions-features-visuals description to open-ended-app-architecture'?
For example, in my app I went from NavBar, to Toolbar with items, to Toolbar with two custom subviews in order to accommodate the functions-features-visuals description. Maybe you have also done such a thing and have some advice to offer?
I'm also looking for open-ended approaches to sharing large ("loaded data") objects, or even simple booleans, between controllers and invoking methods in another controller, specifically starting processes such as animation and loading (example: trigger a load from a URL in the second tab viewcontroller after making sure an animation has been started in the first tab viewcontroller), as these two features apply to the app architecture building approach you advocate.
Any handy pointers appreciated. Thanks guys.
Closing this up as there's no single correct answer and was more suitable for the other forum, had I known it existed when I asked :)
If you want to know the method I ended up with, it's basically this:
Window-based blank app
Navigation Controller controls all, whether I need to or not (hide when not used)
Tab Bar Controller if necessary
Connect everything <-- unhelpful, I know.
Set up and check autorotation, it might get added to some view later.
Add one viewcontroller with xib for each view, you never know when they want an extra button somewhere. It's easier to copy code than make the max ultra superdynamic adjustable tableviewcontroller that does all list-navigation, etc.
Re-use a viewcontroller only when just the content differs in it, such as a detail viewcontroller.
Minimize code in each viewcontroller by writing functions and methods and shove them in a shared .m
Everything that's shared ends up in the App delegate, except subclassed stuff.
Modal viewcontrollers are always dynamically created and never have an xib.
Been researching how to send data from one child view to another child view. The application has several views, where one is kind of real-time Settings view. Changes in settings should effect stuff inside other views.
NSUserDefaults seems to be popular, but I don't want persistent data nor automatic saving into database/file. Looks like potential slowdown, which I want to avoid.
Second popular thing is passing a reference to some common top level object into each child view. Just haven't found any tutorial, which would show me in detail how to do this... Most likely so easy, no tutorial is needed - after you figure it out once! Would appreciate, if you can point me to right direction (URL)!
Question: I'm thinking about using one "singleton object" to store "global data", access it from everywhere anytime. What could wrong with this? If I create it at e.g. appDelegate.m it should exist before anyone tries to access it, right?
I'm looking at this sample code.
I would recommend using delegates and/or notifications.
Instead of creating a new singleton in the app delegate, add the necessary data (or, even better, references to the data) in the app delegate and have the views have references to the app delegate.
You can also set up notifications so that your views can keep track of changes to the data that they display.
The beauty of a singleton is that it is automatically created when you first access it via some [singletonClass sharedInstance]. So you don't need to "create" it while launching. If it is global data that needs to be accessed from any view singleton might be the right way of doing this.