lördag 26 november 2011

I'm back!

It's been a long time since I wrote anything here, I'm sorry about that. I've had a lot to do in school and have not had any time to spend at my own programming projects. Mostly been developing in C# .NET the latest couple of months (School-assignments), so there hasn't really been anything interesting to write here. (Yes, C# is uninteresting..)

But now I'm back, and Yes, some interesting things has happened in my developing career (if you can call it that) latley:

1. I've started working at the Institution for informatics and media (My institution) at Uppsala University as an assistant at the introduction to programming class. The latest month I've had the privilege to hold lectures and helped students in C#. This is really a great experience and you learn a lot by teaching others to program. I got chosen not only for my skills as a programmer (Which still isn't on a professional level), but also because I've studied pedagogy at the University. I guess the thought that was a good combination. I also like to think that my extremely good looks had something to do with it... =). Anyway. It's great fun, and I hope I can continue to work there during my time at the University.

2. I've started writing a Database-sync engine for iOS together with a friend (Who's writing the same engine to Android). This engine will keep a mysql db, and two local sqlite-databases (iOS, Android) in sync. It's coming along slowly but it's great fun too build something this advanced.

Now I want to share some snippets of code with you.
In the sync-engine I've chosen not to use NSOperationQueue, but instead do all my threading with blocks and GCD. This is a great method for that purpose:

- (void)performOnNetworkThreadBlock:(NSDictionary * (^)())block thenOnMyThreadBlock:(void (^)(NSDictionary *))block2
{
    dispatch_queue_t callerThread = dispatch_get_current_queue();
    dispatch_queue_t networkThread = dispatch_queue_create("NetworkThread", NULL);
    dispatch_async(networkThread, ^{
        NSDictionary *dictWithResponse = block();
        dispatch_async(callerThread, ^{
            block2(dictWithResponse); 
        });
    });
    
    dispatch_release(networkThread);
}

You call this method this way:

      [self performOnNetworkThreadBlock:^{
            
/*Do everything that you want to be threaded but it has to return a dictionary. For me this will be the response from the server.*/
//Example:
return [self doNetWorkCallWithDictAndReturnResponse:dictWithRequest];
            
        }thenOnMyThreadBlock:^(NSDictionary *dict){
            
/*This block executes on the thread you called the method from. But will execute first when the network call is finished and will receive the response from the server that we returned in the previous block.*/
            if (dict)
            {
                NSLog(@"Response from server:%@", dict);
//If we called the method from the main thread, it's safe to use UIKit here:
label.text = [dict valueForKey:@"title"];
              
            }
        }];


This is a really useful method, and it makes you see the power of blocks in Objective C.
This one is also really cool, but a bit dangerous:


When someone want to use the sync-engine to sync something, they provide the engine with a block of code they want to be executed when the sync has completed:

- (void)synchronizeEntity:(NSString *)entityName andPerformBlock:(void (^)(bool))block
{
    self.callersblock = block;
    callersThread = dispatch_get_current_queue();
    
   // [self uploadAllNewEntitesWithEntityName:entityName];
    
    [self buildCrossSyncDictionaryFromEntityName:entityName];

  
}

as you can see, the method saves both the block that the user wanted to execute after sync, and the thread the user called the method from in iVars.
they are declared like this:

//The block
typedef void (^CallersBlockType)(bool);

//The thread:
dispatch_queue_t callersThread;


The sync does a lot of things after this. But at the point of completion, or anytime else, I can just do this:

    dispatch_async(callersThread, ^{
       
        //Boolean value depending on result of sync.
        self.callersblock(true);
    });


that's really powerful. But watch out and remember that the user might reference to iVars and local variables in the block. So this should not be executed at an to late point.

Hope you liked those tips!

//Objective Coder


söndag 11 september 2011

Quizer video!

Recorded a short video where I demonstrate Quizer:


Quizer Video 1 from Olof Dahlbom on Vimeo.

One week of PHP-Pain

This past week i've been struggling with PHP. I knew even before going into the week that this would mean pain. My PHP skills are extremely limited and I honestly think the language is a pain to work with. The biggest problem for me is the lack of debugging methods in PHP. I love breakpoints and console outputs for debugging, none of the above is possible when you send code from the iPhone to a PHP-script.

What I wanted to do is to send my JSON-Quiz from "Quizer" (The app I'm working on) to the server. And then parse it into the database. After a weeks struggle that is now working. You can create a Quiz from the phone and load a quiz from the server to the phone. What's left now in this process is to debug the app so it won't crash when the request takes longer time then usual (3G networks can be so slow at HTTP-requests.)

The week ended on a double-happy-note when I arrived home this friday and meet my new best friend, MacBook Air:



MacBook Air "13


The computer is wonderful to work with, and it's so thin and light it's amazing.. I only hope the 4gb RAM will be enough for my use.

This is the PHP script for Quizer if anyone wonders how it turned out (I know it's an easy one.. when you know PHP):

//Code on!

måndag 5 september 2011

MacBook Air

Today there is not much programming going on. But I just had to tell you that I've now ordered a REAL mac! For some time now I've been using an old HP NC6400 with Mac OS X Lion installed on it. Yesterday I took the step and ordered a MacBook Air 13"!

This is my current computer:

MacBook Fail 13"




Yesterday I posted a pic on Ludvig.. this made my other friends extremely jealous so here's a pic of them as well!

Agent Eel & Android!
//Code on!

söndag 4 september 2011

Update on threading

In a previous post ("Safe threading") I talked about threading, and using the method performselectoronmainthread. This method is great for "fast-jumping" from your own thread to the applications main-thread. After using the method for a while I however realized that the method is very constricted. This resulted in a thread on StackOverflow where I asked if there is any smarter ways to jump in and out of threads. I got a great response to the question that really made my threading easier:




Well, you're already using dispatch_async. Then you should just use
     dispatch_async(dispatch_get_main_queue(),^ { ... } );
from inside your background thread to perform things on the main thread. For example,
     if ([self testServerMethod])
        {
            dispatch_async(dispatch_get_main_queue(),^ {
               [self showMessageBoxWithString: @"Server is working!"];
               [self threadedUIActivityRemover:nil];
            } );
        }else ...


This way of calling 
dispatch_get_main_queue()



And then performing UIKit-related stuff is really smooth and much more versatile then performselectoronmainthread. 

So, that's an update to the hole Threading-colundrum. Now on to new things. 
I'm still writing on Quizer as much as I can. And it's slowly starting to take form. Next week I hope to have time to tackle the main logics of the game itself. And thats really something I'm looking forward to. 
To be able to run the app 24/7 I've invested in a small NAS that run Apache and MySql. It will be fun to see how it will handle high traffic-load etc. I'll come back to you regarding that when I'm testing the app in a few weeks!
Today I'm in school programming with my friend Ludvig. He's not the most inspired programmer today.. but after all it's sunday.. 
Ludvig at work!
//Code on!

fredag 26 augusti 2011

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! 





torsdag 25 augusti 2011

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!