Hide a slow network connection

Downloading to the device can be painfully slow. Even fast 3g connections lags when it comes to response times compared to wired networks (It's not all about mb/s). This mean that you have to take this in consideration while designing a Client-Server application for the phone.

Threading is the answer to this. Do your network fetches in the background and you "might" be able to deliver a feeling of responsiveness to the user. Many apps do this by showing an UIAvtivityIndicatorView while downloading information, like this:

This is a great way of telling your clients, Hey!, I'm working here!.. but it will require your client to wait..

You can however solve this neater in many situations by performing background tasks while the user is scrolling though your UI, that does not require the data being downloaded. If you for e.g. know that the user soon will come to a screen that requires downloaded data, Start downloading it sooner rather then later. of course you can argue about the increased network use and battery drainage, but it all comes down to your decision as an developer.

Today I did one of these sneaky background downloads in this interface:

This interface has the button "Choose category from list". This list is being fetched from the server. 

I could have solved this by presenting an UIActivityIndicatorView either when loading this ViewController or when loading the UIPickerview that popes up when you click the button.

Instead I solved it by disabling the button itself and giving it the .text property "Downloading list..."

until the list is downloaded. This way the user can roam around the interface and not be prompted to wait, while still knowing that a download is being performed.

Think about how your user will use your application, and try to be one step ahead at all times!

Code on! 

Need faster protocol declaration!

Apple!
It takes forever to define a protocol in objective C!
Please build a function (outside of IB) that let's you "Define new protocol".

This is how you do it today:
First you have to define the protocol in the class that is going to do callbacks to it's delegate.

@protocol CreateGameProtocol <NSObject>

-(void)userDidCancelCreationOfGame;

@end

This is put above the @interface declaration in the .h file.

Then you have to create a property for the delegate in the property section of the same .h file:

@property (weak, nonatomic) id<CreateGameProtocol> delegate;

Remember to put Weak and not strong there! Why? you do not want the to have a retain from the subclass to it's owner. Only one should own the other!

then you have to implement the protocol in the delegate class:

@interface GameViewController : UIViewController<CreateGameProtocol>

Just put the name of the protocol in "less-then, greeter then"-signs.

Remember to import the .h file of the subclass in the delegate for it to "see" the protocol!

then you have to define the callback method in the delegate .h file.

#pragma mark -

#pragma mark Protocol Methods

-(void)userDidCancelCreationOfGame;

Then you have to call the method from the subclass .m file.

    [delegate userDidCancelCreationOfGame];

And of course assign the property of "delegate" to self when you create the subclass in the delegate-class:

        

    createGameViewController.delegate = self;

That is what I call a hassle for something that easy....

I'm lucky there is ctrl-v ctrl-c in these situations!

Safe threading!

The importance of threading safely has become clear when working on SC. At many times my background treads has come in touch with UIKIT (Not thread-safe) and crashed. if you e.g.. want to check a value against the server and display different ViewController's depending on the result, you cant't do this on the background thread.

This is my way of doing that (Might be better ways out there):

dispatch_queue_t loginThread = dispatch_queue_create("Login-thread", NULL);

    dispatch_async(loginThread, ^{

    

        NSArray *arrayWithUsernameAndPassword = [NSArray arrayWithObjects:userName, password, nil];

        

    if([dataParser loginOnServer:[self requestActiveServerData] withUsername:userName andPassword:password])

    {

        [self performSelectorOnMainThread:@selector(threadReturnLogin:) withObject:arrayWithUsernameAndPassword waitUntilDone:YES];

    }else

    {

//Should be a rejection here!

    }

    });

    

    dispatch_release(loginThread);

    

     [self performSelectorOnMainThread:@selector(threadReturnLogin:) withObject:arrayWithUsernameAndPassword waitUntilDone:YES];


is the solution to the UIKIT problem. This executes the function on the main thread instead of the custom one!


Happy coding!

Got a crush on Charles!

Charles is a great application for debugging Server Connector!
If you're writing a http- or SSL-based application, test Charles!

A working module!

Hi!
Been working a lot lately and have not been able to update the blog. I've however been able to squeeze in a few hours of programming between work and Server Connector is really starting to pay off.

I've been working on creating an well organized and easy to grasp API for Server Connector. And for doing that I've started writing a app called "Quizer". This app is been developed for the sake of Server Connector. You have to work with the module in a "live" situation to see what there is to correct in the API.

The API is turning out great, and is a breeze to work with. You can essentially call any function of SB right from the ServerConnector.h class.

This is a few screens from Quizer:

As you can see, you can launch SB right from the UI or just call it's functions from the source!

Neat..

ServerConnector 0.1 Alpha

Now you can download the first Alpha of Server Connector.
Get the source at my GitHub!

For a server to be accepted and added it needs to return string value "true" without quotes.
The ID is sent to the server. So check that the ID is correct and return true.

This is my simple php-script for that, that accepts the ID "1":

<?php 

$clientID = utf8_decode(strip_tags($_GET['clientid'])); 

if ($clientID == '1')

{echo 'true';}  

else

{echo 'false';}

?>

 ServerConnector 0.1

Enjoy!

ServerConnector is moving forward!

Server Connector is almost finished now!.. at least all the code is. But what I have promised myself when writing these "modules" is to be very pedantic about commenting the code and to make all code execute and read smoothley.

At this point you can add a server to the List of servers, which is then written out to a .plist file containing all servers. Then the UIPickerView reads all the servers in the lists and lists them by name. You can then delete, test, choose or view details about the all the servers. When you choose a server from the list, this server is written to another .plist-file. It is from this file all other modules/apps will be able access the active and tested server.

It really surprises me how much code this small app has generated. The amount of code needed to make sure all lists are in sync and all connections to the servers are checked correctley takes time to write.

Right now I can't get the app to crash, and it does what it's set up to do. 

My next step is to test this app against a remote server, and thread the app so it won't stutter and show an acivity-wheel while waiting for a server replay.

When all is well with the app itself. I will Comment code, structure code and make the app as accessible as possible for the other modules!

Here is some screens after todays work:

Tomorrow I will go back to my job as sound engineer, so I might not be writing for a few days!

As always, Code on!

//Objective Coder

Three screenshots from "Server Connector":

Xcode beta 4.2.. Slow down Apple, I can't keep up!!

I started using Xcode at the beginning of this year. At that point it was Xcode 3.2, and besides the standard concepts of Objective C, everything has changed since then.

Just when I got a grip of Xcode 3, Apple launched Xcode 4. An all new "One Window" experience with a lot of new features to learn. This confused an already confused programmer, but I powered through and started loving Xcode 4.
During the spring I developed my first iOS app called "Soffning" for a school project. It was a great project to start with. It had a lot of ViewControllers and became quite big at the end, and it really gave me a feeling of satisfaction when I was able to demonstrate this app for an entire class of peers, that I at least hope, was impressed.

During the summer I've been working as an sound engineer and has not been able to write as much code as I hoped I would. Now when the autumns here I've been getting back into the game and Have been starting to form a game plan for this years off-hours programming.
I will try to develop modules rather then entire applications during this fall. Modules that can be reused in coming projects. The first of these modules I call "Server Connector"

Server Connector will be an app for both the iOS and Mac OS X Lion. The app will in it self be quite useless, but will in a longer run hopefully prove to be a time saving resource.
Most of my planned applications will connect to an online PHP/MYSQL server for communication. And "Server Connector" will do exactly what the applications name promises. It will connect the application to a Server. Why is this useful?
                                                                                                       
 - To save time and not having to rewrite the backend for each application that uses a server connection
- By having the code divided into modules/components it’s easier to update and stay organized. If you fix a bug in the server connector it applies to all applications that uses that module.

So, back to topic, I’ve started developing this module in the Xcode 4.2 Beta. And yet again I’m facing a lot of new stuff from Apples side. The major differences are as follow:

- ARC. Automatic reference counting. As you might know garbage collection isn’t available when you develop to iOS, which means that YOU have to keep track on when to release/destroy your objects. This is a double-edged sword, but Apple is trying to make it easier for developers by introducing ARC. With ARC you no longer have to manage your own releases. The system does that for you. That does not, however, mean that ARC is garbage collection. Just an automatic system for releasing objects.

In my opinion this system has potential, but there are still some question marks that needs to be sorted. I do however raise a question to Apple here. If they intend to hide object management this well, how will new programmers be able to learn and tackle problems related to Reference counting and memory leaks. To conclude, it’s a pain in the ass to take out your own garbage, but it gives you control over the application and you’ll learn a lot by doing it yourself. I’m glad a learned to write Objective C in the pre-ARC-era.

- Storyboarding. The next step for interface builder. My guesses are, that I will love this system once Apple get the bugs sorted out (And there are a lot, it crashes five to ten times a day.(I Know,it's only a beta.) and I get a grip on the fundamentals. Storybording let’s you develop your entire applications GUI in one window where every screen is called a “Scene” and every transition between “Scenes” are called segues. What it let’s you do is to design the interface without having to write a bunch of code. This is extra great in iOS though the number of ViewControllers very quickly can become hard to manage. Storyboarding together with ARC and weak referencing speeds up the process of designing GUI a lot. In theory there are some worrying signs of this new system though. It all becomes a little…hmm.. can I say Adobe (Flash) with all it’s dragging and dropping. And In my experience the easy isn’t always the best. When Apple use this approach and hides a lot of the code It also makes you feel a bit out of control.

Server Connector uses both ARC and storyboarding. My timeframe for this small application is only one week. It’s, as I pointed out, a very simple application. In that week, time for commenting code and make it accessible is also committed.

Download the project at my GitHub and give me idea and criticism if you like to.
And as always (Twice so far =): Code On!

//Objective Coder

printf("Hello world!");

I've always been facinated by programming. The ability to mix technical skills with artistry to create is somehing very appealing to me and it's that thought that have lead me here!
This recent year I've been starting to learn how to develop for Mac OS X and IOS. Before this I've only written a bit of C#.. So I'm what you can call a rockie at this.

In this blog, that I write mostly to keep my own thoghts sorted, I will write about my experience while developing apps and applications (Nice double use of the same word, but you know what I mean.)

The code for most of my projects will be avaliable for you to download at my GitHub.

I hope this will be the perfect blog for me to express my sometimes confused encounters with API:s and SDK:s and that I sometime in a distant future will be able to get some people to visit this blog for help with their own coding experiance!

Code on!

//The Objective Coder