Saturday, January 28, 2012

Get Data from address book without displaying the address book modal controller

At times it might be required that you have to get only the data from your contact list but should not display the address book modal view controller, so in todays post we are going to see something like this. (For earlier data on address book framework kindly refer to my earlier blog post here).


Step 1: Create an empty xcode project and create a view which looks like the one given below. The gray portion consists of the table view controller so don't forget to add the datasource method of the table view controller which are given below:


1. - (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
2. - (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
3. - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath









Also connect the datasource and delegate property to the file owner if you are using the interface builder or set the property to self if you are coding this view.  Once done add the address book framework into your project and import it into the .h file of the AddressBookNamesViewController


Step 2: In the .h file of the AddressBookNamesViewController declare the function and an array, in the array we shall retrive the names of the person inside your address book given below is the code for the same
















Step 3: Select the dot m file and now in the .m file we will code for the function given below is the code for the same.
















Don't forget to connect the function with the buttons touch up inside method also i have given memory to the mutable array in the init method of the AddressBookNamesViewController.m file


Step 4: Its time to code for the datasource method of the table view


























Step 5: Select the app delegate.m file and add the AddressBookNamesViewController view into the iPhone window but make sure to import the AddressBookNamesViewController.h file into the app delegate.m file before creating its object.
















Finally run the application and hit the button to see the names o fall your contact as a list in the table view.






You can download the code from here.


Happy iCoding and have a great day.



ARC Part 4: Simple ARC project Demo

In todays post we will learn on how to create a small arc demo from the scratch.


Step 1: Open Xcode and create an empty application and give it an appropriate name (for this demo i will go with the login demo), 




When you hit the next button the xcode will ask you for the name of your project after entering the name of your project make sure that you select the use Automatic reference counting check box as given in the below image




Step 2: Create a view which looks like the one given below with the help of coding or via interface builder as per your convenience


Step 3: Now create the IBOutlets and IBAction for the view that you have created since its a view with a login button and a clear button then in this case their will be two functions make sure that you give your naming conventions properly, given below is the code for the same.




Step 4: Now select the appdelegate file in your project the and create the object of this view just like this




try running your app, when you will hit the login button your application might crash and you will get the error message in your log only if NSZombie is enabled


You have got this message because of the way you have created the object of the LoginViewController, the view that you want to show in the iPhone window must be of strong reference and this is why your application crashed (For more details refer my earlier blog on strong and weak pointer reference) the code for the same is given below 

In the app delegate.h file



In the app Delegate.m file synthesize the property of the LoginViewController


After doing this update the code in the application did finish launching method


Step 5: Now you are ready to run your first ARC application go ahead and run your app everything will be just fine.

In my earlier post i have mentioned that not all third party libraries support the concept of ARC till now so for that when you convert the project into ARC then just uncheck those libraries which might give issue but make sure that in the Build Phases of your project you add a small command line. 


I hope that you have got the concept of ARC and how to create app and convert app using ARC, if you have any queries then kindly let me know via comment or via mails until then Happy iCoding and have a great day.

Sunday, January 22, 2012

ARC part 3: Convert existing project into ARC



You may convert an existing app of yours to ARC without any issues, after converting your app to ARC you will get a huge error list wherever in your app you have made calls to release, retain or autorelease.There is one simple way to do this and that is let your xcode do the conversion for you and for that all you have to do is from the edit menu of the xcode select refractor and then select the convert to objective c arc option.



While doing this conversion xcode will guide you on what all changes will be done to your project just go with the flow and finally you will have your project converted into ARC.

Once it is done try to build your application you will get a list of errors where ever you have used retain, release or autorelease just remove call to those keywords and the app should be fine.

Run your application to make sure that its running smooth and if not then go through your code and see where the problem is and remember the concept of strong and weak pointer in case of any issues.

In my next post i will show you how to build an application from start by using ARC.

Happy iCoding and have a great Day.

Friday, January 20, 2012

ARC Part 2: Strong and weak pointer system


Strong and weak are keywords that help you manage the Automatic Reference Counting (ARC) of the XCode environment and are a part of the new way of managing memory in Objective-C. To understand the difference, you must first understand how memory is implicitly managed by objects in XCode.

Each object has a property that tracks the number of other objects that require/reference it. This property is called the reference count. In the old way of doing things, you would specifically tell the object to be retained (increase its reference count). When you did this, you would also have to explicitly tell the object to decrease its reference count (release) when you were done with it.

When an object’s reference count reaches zero, it is destroyed and its memory return to the heap where it can be reused. If you forgot to retain the object, it could potentially be destroyed earlier than you intended and cause an error in your program—there are reasons why you wouldn’t retain an object. If you forgot to release the object, or you write code in such a way that it could never be released then it could reside in memory even after you were done with it, causing a memory leak that could slow your app down or even crash it after sometimes.

Now, with ARC you no longer have to explicitly tell an object to be retained or released. Pointers are automatically created with strong references; they are automatically retained. In this case, the strong keyword is implied when creating pointers, though you can use it if you want.


NSString *nameString = self.nametextField.text;

the nameString variable becomes a pointer to the NSString object that holds the contents of text field, thenameString variable is now the owner of that string object.

An object can have more than one owner. Until the user changes the contents of the UITextField, the text property of UITextField is also an owner of the string object. There are two pointers keeping that same string object alive:


Moments later the user will type something new into the text field and its text property now points at a new string object. But the original string object still has an owner (the nameString variable) and therefore stays in memory.


Only when nameString gets a new value too, or goes out of scope — because it’s a local variable, or because it’s an instance variable and the object it belongs to is deallocated — does the ownership expire. The string object no longer has any owners, its retain count drops to 0 and the object is deallocated.

We call pointers such as nameString and textField.text “strong” because they keep objects alive. By default all instance variables and local variables are "strong pointers".

However there are times when you don’t want to retain an object (i.e. increase its reference count). To do this, you use the weak keyword when creating the pointer. Your pointer will still point to the object, but if that object is destroyed then using the pointer will cause a program error.

Why would you use a weak reference?

Well, one reason is if you have objects in parent-child relationships where the parent keeps pointers to its children and every child keeps a pointer to its parent. The potential with this structure is that you could no longer need your parent object and XCode will implicitly release it, but because its children keep a reference to it, the parent and its children can remain in memory even though you no longer have a way of accessing them. This is called a retain cycle.

To avoid the retain cycle, the children objects should only maintain a weak pointer to their parents. The reason for this is that when the parent is told to destroy itself, the children would be destroyed first so there is no chance they could access their parent after it had been destroyed.

Here’s a link to apple doc that explains it much better:


Just because ARC takes care of doing retain and release for you in the proper places, doesn’t mean you can completely forget about memory management altogether. Because strong pointers keep objects alive, there are still situations where you will need to set these pointers to nil by hand, or your app might run out of available memory.


If you keep holding on to all the objects you’ve ever created, then ARC will never be able to release them. Therefore, whenever you create a new object, you still need to think about who owns it and how long the object should stay in existence.There is no doubt about it, ARC is the future of Objective-C.

Apple encourages developers to turn their backs on manual memory management and to start writing their new apps using ARC. It makes for simpler source code and more robust apps. With ARC, the developers are assured that the memory related crashes will no longer be their head ache.

Note: You may often come across code that isn’t compatible with ARC yet, whether it’s your own code or third-party libraries. But you may convert it to ARC I will show that in my next post.

Hope you have understood the concept of strong and weak pointer system, if you have any queries kindly mail me or ask them via comments.

Happy iCoding and have a great day.

Automatic Reference Counting (ARC) Part 1


What is ARC:       

ARC or automatic reference counting is a new concept that is added in the latest xcode with this feature you need not worry about managing your objects the LLVM 3.0 compiler which is newly added by apple will take care of it.

This means now you don’t have to retain, release or autorelease an object with ARC all this is done for you by the LLVM 3.0 compiler this is something very cool and very neat that apple has done for its developer.

How can it make developer life easy?

Earlier in objective c we had to do manual memory management which had the below rules:
·         If you need to keep an object around you need to retain it.

·         If you are the owner of an object you will release the object when its not in use.

·         If you want to stop using an object you need to release it, unless you have used autorelease.

Imagine earlier before ARC we had to manually implement the retain, release and auto-release code in our application which was a bit tuff at the start but once if your familiar its a piece of cake.

Manual memory management at the beginning is a tuff task and even if you master it your are not 100% sure that you have taken complete care of memory at times mistakes due happen and these mistakes could lead to huge consequences called as “crash” because it might happen that you are pointing to an object that you have released or it might happen that you run out of memory if you have not released your objects well.

It is important to realize that ARC is a feature of the Objective-C compiler and therefore all the ARC stuff happens when you build your app. ARC is not a runtime feature (except for one small part, the weak pointer system), nor is it a garbage collector.

All that ARC does is insert retains and releases into your code when it compiles it, in the same way like we do it during the manual memory management. Also not only this LLVM also guides you during the development process and helps you fix minor bugs when you make mistakes as it is continuously evaluating what you type and identifies the coding mistakes that you make and also fix it for you.


Hope that you have got the initial concept of ARC in my next post i shall explain what is  strong and weak pointers, until then happy iCoding and have a great day.

Check list before submitting iOS app to app store and tips


  1. If your application is using webservices then before submitting the app to the app store make sure that the application is pointing towards the webservices in the production server and not the testing server.
  2. Delete the app from your device, turn off WiFi, off cellular data, now install and test app. Does it work properly (as much as it can without Internet)? Does it at least tell the user that a network connection is required (if it is) or does it crash?
  3. If you use CLLocationManager: Delete the app, fresh install and run, but do not allow app to have Location Data. Does the app behave well or does it crash? Does it at least tell the user that it can't run without location data (if that is a requirement)? Does it work on an iPod Touch that does all geo location using WiFi only?
  4. Run the app in the simulator and for each view controller do the following steps: (a) From the iPhone Simulator menu select "Hardware" --> "Simulate Memory Warning",
    (b) now navigate around your app to other view controllers and see if everything is working.
    (c) repeat test for another view controller.
  5. If you support older firmware (ie: iOS 3.1.3), install your app on a device running 3.1.3 and test it there (if you don't have one, use the 3.2 simulator).
  6. Accept a phone call while in your app, does it resign active and resume properly? Do sounds from your app stop playing while in the phone call?, Also you can test the application in the call mode in the simulator all you have to do is select the hardware menu from the iOS simulator and select Toggle in-Call Status Bar.

  7. Start your app while playing music, does the music continue to play? Do your sounds mix properly or fade the music appropriately?
  8. Test performance on a slower devices with limited RAM such as: iPhone 3G (128MB RAM, 412Mhz CPU) or iPod Touch (1st or 2nd gen).
  9. Run the Clang static analyzer and fix (or at least understand) every warning.
  10. Make sure NSZombiesEnabled is NO in the environment variables.
  11. Make sure that you remove all the crashes from the application as this may lead to rejection.
  12. Make sure that your app does not become slow due to memory leaks after using it for sometimes.
  13. Is all the functionality you describer in iTunes Connect available in the app and if not then get ready for the no signal from apple.
  14. Do not show price of your app inside the app.
  15. If your app contains some login stuff then add the demo login credentials in the review notes.
     
  16. If your app contains brand names, description or keywords of well known public figures or trademarks make sure you get them all cleared with the holders.
  17. Your app should not contain any media, code which is copyrighted by others. If so then you should contact the owner and get the approval from them.
  18. Do not use any private libraries which are prohibited by apple or any undocumented feature of the SDK.
  19. Have you followed all the steps of the Human Interface Guidelines (HIG).
  20. Trial versions of app are not supported make sure that our application is not a trial version.
  21. If your application makes use of any hardware unauthorized by apple then your app will be rejected.
  22. Your app should not contain a runtime plugins, or interpreted code layer.
  23. Turn off all the NSLog in the application.
  24. In case if a new version is introduced with the new design then in that case you have to change the screen shots of the application which was previously submitted to the app store with the new design interface of your application.
  25. In case you app is a medical app then you must fulfill any applicable regulatory requirements, including full compliance with all applicable laws, regulations, and policies related to the manufacturing, marketing, sale and distribution of Your Application in the United States, and in particular the requirements of the U.S. Food and Drug Administration ("FDA").
  26. If you are submitting a new version then in that case make sure that the bundle version of your application is greater than 1.0

Tips2Code: Many developers come across crashes which they are unable to locate then in that case i would suggest to run the application by selecting profile from the xcode menu which will enable the instruments and from the instruments list select the Zombies, which will give you exact details why your app is crashing.

- Avoid using loops for doing simple stuff.

- Make use of switch case in place of if..else

- Use core data and not sqlite for database coding as core data is way to simpler as compared to sqlite.

- JSON is a blessing in case of webservice and faster.

- Unit test the module yourself and then confirm it. In short test the app like  user and not like a developer.

- Follow MVC module as it simplifies lots of task in your project.

- In case if you have done a major task then prepare a library for the same which can be reused by other developers.

- Release all your objects in dealloc but if an object is local then release it then and their don't make it global.

- If you are releasing some view like the map or the picker, table view then make its delegate and datasource method nil.

- Do not release an IBOutlet it is handled by the xcode itself, if you do you will get a memory warning their saying that incorrect reference counting which will lead to crash.


I hope that the above check list helps you by preventing rejection of your precious iPhone application.

Happy iCoding and have a great Day.
Radix