Justin McCandless

I’ve been working on this open source side project of mine for a bit, and I just submitted it to Mozilla Demo Studio, so I thought I’d make a quick post about it here. I wanted to take a tried and true design, the simple notebook-paper-stuck-on-your-fridge task list that you’ve probably seen other apps replicate, and completely reimagine it using the web and HTML5. The result still isn’t much more than a concept, but I think it’s a great example of something you can do with the web.

If you're looking for an easy way to get all of your front end code ready for production with one command, a tool called grunt can help you do just that. Well, depending on your definition of easy. Once you have it set up and know what you're doing, grunt makes it incredibly simple to compile coffeescript/sass/compass, lint your js, minify, concatenate, and a lot more. However, since it is very new and the documentation is still not fully complete, getting your first simple build off the ground can be more tricky than just doing everything by hand one more time.

Googling around for a jQuery carousel the other day, I found that the market consisted of literally tons of solutions, many of which were not open source and actually required you to pay to use them! This was a huge change from I first created my original jQuery carousel project because there was almost nothing to be found back then. The lack of quality caused me to go back and dust off my old project and bring it up to standards, while of course keeping it as free, open source, and easy to implement as always.

In my previous post I showed how to perform asynchronous web API calls in native Android code, after showing how to do it in native iOS a few days before. My Android post was glaringly missing support for callback functions however, so today I'll show how to add that functionality in the Java world. First we'll need to add some code to the class from where ApiCall is called. This will be what represents our reference to the callback function that we can call from an ApiCall (thanks to this Stack Overflow post for how to do this).

During my small look into web API calls in native iOS, I thought I would also take a look at Android to compare. My first impressions were all positive with the much more C++ like syntax of Java and the XML based layout. I quickly ran into my first hours long problem to solve in simply calling a web API, however. The problem this time wasn't a lack of information available online, but actually so much that it was difficult to sift through it all and find a working example.

Madness was the only thing I could call viewBox's behaviour during the first few hours I spent researching and playing with examples. After finally figuring it out by reading way more of the W3 spec than I had planned, I decided to write a more user-friendly introduction to viewBox here. I encourage you to follow along and play with different possible viewBox set ups as we go. Open up my viewBox sandbox (source code) and try out the examples in this article for yourself, or just use your browser's dev tools directly on the SVGs below.

The main thing that people jump to criticize HTML5 apps about over their native counterparts is speed. One of the easiest ways to make up this difference (and one of the obvious shortcomings of jQuery Mobile in iOS) is in click speed. By making sure your click events are firing as fast as possible, you can often cut a lot of the lag in page transitions and other events without much work.

I've been dabbling in Objective C at work recently when I'm not doing HTML5. I found myself needing to make several API calls to external web servers, so I attempted to write a nice class to handle this, including callback functionality. Let's look at the code. ApiCall.h #import @interface ApiCall : NSObject // The callback function pointer @property (nonatomic) SEL *callback; @property (nonatomic, retain) id delegate; // The network response data stream @property (nonatomic, retain) NSMutableData *dataStream; // The main public call function -(void)call:(NSManagedObjectContext *)managedObjectContext : (NSString *)apiUrl; @end ApiCall.m #import "ApiCall.h" #import "SBJson.h" @implementation ApiCall @synthesize callback; @synthesize delegate; @synthesize dataStream; // This function makes a call to the given url, and on connectionDidFinishLoading calls the given callback -(void)call: (NSManagedObjectContext *) managedObjectContext : (NSString *)apiUrl { // create a fetch request and set the entity NSFetchRequest *request = [[NSFetchRequest alloc] init]; NSEntityDescription *entity = [NSEntityDescription entityForName:@"Event" inManagedObjectContext:managedObjectContext]; [request setEntity:entity]; // Execute the fetch request NSError *error = nil; NSMutableArray *mutableFetchResults = [[managedObjectContext executeFetchRequest:request error:&error] mutableCopy]; if (mutableFetchResults == nil) { // Handle the error.

App.net, the $10/month social network initiative by Dalton Caldwell, recently announced its developer incentive program, which pays developers on their platform based on a usefulness survey given to users. This is once again in stark contrast to the other big players, whose developers mostly end up paying them for API bandwidth. Is this step in the right direction for creating the open social platform that users and developers are looking for?

jQuery has a lot of convenient functions for working with the DOM, but if you've tried using it in a similar way with SVG, you may have noticed that for some things it just doesn't work. Digging into the bug tracking of jQuery shows that for some of the issues, there is actually not much interest in fixing this. Here I'll quickly go over a few options for circumventing this and some quick code to patch a few.