I got a few questions about Objective-C structure. I think I can not figure out the entire structure.
Am setting up connection to the server. Using FacebookSDK and ASIHTTPRequest and SBJSon. I use almost in all classes. FacebookSDK appDelegate used to. I use the same functions is too. For example, take a different user profile.
Do I have to collect one class of functions of Request? How do I do?
In terms of performance, whether programmatically or xib files do I use?
Your performance is the most important. XIB files are almost always going to take you less time to create and debug. I guarantee you that talking to the server is going to take far more run time than loading objects from a .xib.
Related
I am preparing an iPad app using, obviously, Objetive-C and wich tries to deploy Data Base stored content inside a view.
Now comes the problem, it will be a huge amount of records to be shown, each of them deployed inside some kind of "container" inside the view so that I was considering to make a page browser and in every page I go to change the view I apply.
Take for example, I show the first 5 items using example1.xib, for the next 5 example2.xip and so til getting to the page 10 and starting again with example1.xib.
My question is how this can be achieved? Maybe storing diferent view class based objects inside an array and alternating them or so...
Any help or hint would be greatly apreciated.
Cheers!
Always assume others have made similar apps before you. Perhaps not exactly the same ones as you, but doing similar things that you can learn from. The iPod and Spotify apps navigate large amounts of data using indexed, searchable TableViews. Go hunting on App Store for apps that have the same kind of functionality as yours, and test them out and grab what's good and discard what's bad about them.
My advice is to get hold of a nested tables example using the built in SQLite, and go from there. I've no idea what your database looks like, but with a bit of luck you could adapt example code and just open (a converted) SQL database.
Most users by now are used to the drill down paradigm rather than the paginated paradigm, so it's worth checking out the Drill Down example that comes with XCode even if it's not for databases (at least I don't think it is, I learned from a book, like Manuel.)
I would subclass UIViewController or UITableViewController depending on what type of records you plan on using.
I would recommend checking all the Apple's Examples, and most of the available online tutorial
Here are some, may be old though...
http://www.edumobile.org/iphone/iphone-programming-tutorials/tabbarcontroller-with-navigationcontroller-and-tableview-in-iphone/
http://www.aboveground.com/tutorials/adding-a-uitableview-to-a-custom-uiview
http://www.icodeblog.com/2008/08/08/iphone-programming-tutorial-populating-uitableview-with-an-nsarray/
http://blog.webscale.co.in/?p=150
http://www.ioschef.com/2011/03/un-aperitivo-de-uitableview-y-uitableviewcontroller/ in spanish..
http://adeem.me/blog/2009/05/19/iphone-programming-tutorial-part-1-uitableview-using-nsarray/ with videotutorial
If I have a tab bar app, and plan on using Core Location in different tabs, is there a good common place to put the code used to alloc/init the CLLocationManager, and get the updates once startUpdatingLocation is called? Or if it's going to be used in two different tabs, do I then just put it in the code for each tab? Just wondering what best practices are since I am new to programming. Thanks.
I don't agree with John, the AppDelegate is the "easy" way to do it, but not always the better.
I would do this with a singleton. You can look at Matt Gallagher's article on Singletons, AppDelegates and top-level data for reference.
if you notice you're duplicating what you've written, or faced with writing code which exists, consider creating an interface (object, set functions, etc.) to handle these tasks.
see DRY (do not repeat yourself). there will be a lot of duplicate functionality by the time you've written a few apps. it's best to write it once, and to write that correctly.
here are some high level guidelines:
don't put app-specific features in a common interface (instead, use a subclass shared by the 2 projects)
always keep your bases free of hacks (unless you're dealing with an issue in the system libraries). if clients (e.g., subclasses, callers) need a particular workaround or require a specific check, then it is better to make them handle it.
use assertions to ensure they use the interface as intended, check every argument, precondition/postcondition, the state of your object, etc..
keep your objects/interfaces very small and maintainable, with a clear purpose of their intended use. naturally, this will result in a higher number of objects.
avoid the urge to use singletons and static data; there's almost always a better way even if it's as simple as forcing clients to create an instance of your class.
create libraries with these interfaces, and divide them logically.
now that that's covered…
i'd begin by using (potentially multiple) instances of the objects you'll need. there is nothing in the documentation that states "you should not create multiple instances of the object".
if this is somehow inadequate in profiling, then consider using a shared object which relays messages to the objects (in your app) which need updates.
rationale: chances are, apple's already optimized the implementation, so you don't have to.
finally, i broke these guidelines in an app which required a ton of location requests, and displayed a ton of location information. the app used some static data behind an interface which stored the location manager and the location (among other things). so i ended up using static data with private (hidden) static data to reduce the memory and cpu demands in this case.
The App Delegate is a good, central place for such data. You can always get to the app delegate with [[UIApplication sharedApplication] delegate]
I've been playing around with iOS development and I'm getting to the stage where I want to create something beyond a simple app. However, I'm not confident that I understand how to partition an application correctly.
For the purposes of simplicity, imagine a (very) simple audio player application. Let's say there are two view controllers, accessible via a UITabBarController which is instantiated the main AppDelegate class.
Each of these view controllers has the following responsibility:
PlayerViewController - A sound player which plays the “current” audio sample when the user presses a button.
SelectorViewController - A sample selector, that uses a UIPickerView to display the available audio samples so that the user can select which sample they want to play.
So far, so good. However, what I don't quite understand is where I should store the data on the available samples, so that both of the views can find out information on the available samples, trigger a sample to play, etc.
As both view controllers need to access this “model level” information, would creating an “audio manager” singleton class be a sensible approach, or is there (much, much more likely I'm guessing) a better means of solving this problem that I'm overlooking.
Any pointers would be much appreciated.
I've used this pattern (Singleton data manager) several times in serious apps. It's quite straightforward, easy to understand, easy to use, although this pattern is despised by OOP purists.
If nobody tells you it's wrong to use a singleton, go ahead, just be sure to check Apple's documentation on the recommended implementation (there is a bunch of methods to overload).
Oh and BTW, Apple uses it a lot in the iOS SDK, so it's a common practice (see class methods beginning with 'shared').
UPDATE:
Another possibility is reusing an already existing singleton, the Application delegate for instance. It might feel cleaner, or not, it's more a matter of taste. It has the advantage of giving a clear "entry point" where you allocate/create/init your data manager.
If the source of your data is in a remote server and it comes to your app as an XML file, you can also get it whenever you want with a kind of source downloader class.
That way you don't have to care about keeping things in memory when they are not necessary. Just get it from the remote source, parse it and then release it.
Another way of achieving this more careful use of memory is to get your data from a sqlite database using Core Data. But some people thinks it is too much complicated for a simple app and prefer running queries by hand.
I know that there are better ways of sharing objects such as distributed objects but my situation is quite difficult. I'm working on two iPhone apps which are running parallely and need to share an object. That object happens to be a CALayer and it needs to be accessible by both applications. Second application adds its own CALayer to the first app's CALayer and does its work there.
The only way I see is using Shared Memory, but I couldn't find any useful examples of doing exactly what I need. Could someone demonstrate pushing the pointer into shared memory, then retrieving it and serializing it back into the CALayer object?
P.S.: I am aware of the AppStore policies and I don't need another lecture regarding them.
From Memory Usage Performance Guidelines:
The functions used to create and
manage shared memory regions are in
the /usr/include/sys/shm.h header
file.
See also mmap(2), shmctl(2), shmget(2), compat(5)
Don't expect to find a lot of examples for this. This isn't something that is used very often these days. It's old school BSD and plain C. It will only work on a jailbroke device. You'd be better off looking under plain Unix or even Linux resources than Apple API specifically.
Private pasteboard with a name that only your apps know. That's shared memory by other name, and you get free change notifications and stuff.
Is there any reason to not write iphone apps without useing the interface builder?
(or in other words, is it ok to write apps without the builder?)
Personally, my applications use no NIBs within them, but that's more of a matter of how I started doing development than anything else. I transitioned over from doing Mac development (where I use Interface Builder almost every day) to iPhone from when the first beta SDKs were released. Initially, there was no Interface Builder, and even when it came you couldn't do a lot of things with it, so I never took the time to really get to know it on the iPhone. It's more a matter of me doing what I'm familiar with.
Jeff LaMarche makes a convincing argument in his article "Don't Fear the Interface Builder" for you to use Interface Builder wherever you can, and I encourage new developers to learn to use it first before dropping down to programmatic user interface generation. It saves you a tremendous amount of time for interfaces using standard elements.
Some people have argued that there is a performance benefit to be had using purely programmatic interfaces, but Matt Gallagher ran a series of benchmarks and found that this speedup is only typically on the order of 5-10%. If you really want to shave that last bit off of your application's startup time, you might be able to have the best of both worlds with Adrian Kosmaczewski's nib2objc, which generates Objective-C from your NIB files.
However, there are plenty of times that you'll need to manipulate interfaces programmatically, such as for custom views and animations. This code can exist in parallel with Interface Builder without too much confusion. Again, it's more of a matter of personal preference at this point, but my recommendation is to use Interface Builder due to the time it can save you.
I've never written an iPhone app that uses Interface Builder (.xib files), but that's just personal taste: I like applications to be 100% code.
The reason is that I don't like applications that require design-time tools if you need to change something later on. It creates a dependency that may not be a problem today or next month, but it can become a problem in 3 years time.
So, the answer is: yes, it's fine to write iPhone apps without using Interface Builder.
Sure, it's absolutely fine to write apps without IB. It takes a little bit more setup (I believe there are some modifications you have to make to your Info.plist file), but it's certainly possible, and people do it all the time.
Personally, I prefer using Interface Builder for most tasks, but usually just to get the basic layout in place (so I don't have to deal with calculating rects, etc). Any further customization I prefer to do in code.
You can edit .XIB files by hand if you want to. They're XML, after all. Can't help having at least one of them in the project. Alternatively, you can create all your controls from code. The latter takes less typing, as far as I can tell.
Then, there are some apps where a XIB file would be of no use. I'm talking about games, where artistic/design considerations beat the convenience of having native widgets.
So yes, it's OK on both design level (no native widgets) and implementation level (yes native widgets, but sans IB).