]]>1 | if (appBridgeType && [dictionary[FBAppBridgeTypesMetadata.tag] isEqualToString:FBAppBridgeTypesTags.png])
|
The bit that interested me in particular was the use of FBAppBridgeTypesMetadata.tag and FBAppBridgeTypesTags.png which seemed to be strings and constants. I've used string constants before, but have never seen this .xyz construction.
It turns out its a simple struct:-
1 2 3 4 5 6 7 | static const struct { NSString *data; NSString *png; } FBAppBridgeTypesTags = { .data = @"data", .png = @"png", }; |
I do rather like the way this is so self-contained. Must endeavour to learn a bit more C!!
]]>In line with my focus on Objective-C for native iOS development and Node.js for everything else, I thought it'd be a good idea to see how easy it would be to use node to generate the labs and blog sites…
A quick search threw up a few examples where people had moved from Octopress to a node.js based system; the first I tried was Hexo. It claims “Hexo supports GitHub Flavored Markdown and all Octopress plugins and highly Jekyll/Octopress compatible.”, which turned out to be true (more or less).
Assuming you already have node and npm installed, its very easy to get started and I was pleased to see that my markdown files just dropped right in, without any changes.
Fortunately, the theme (Greyshade) that my sites is based on has been ported to Hexo, so it was a simple matter to port the relevant bits across. Hexo supports a number of different CSS and template engines including the one I'm most familiar with (SASS).
Other than a few minor tweaks, it took very little to get it all running pretty much exactly as the Octopress version was. The advantage for me is that if I want to dig any deeper, I don't need to learn any ruby, just use the javascript / node, I already know.
]]>For the most part, it has been an excellent experience, and I'd recommend it to anyone needing a hosted backend solution for a web, desktop or mobile application. There are however some gotchas which you may need to be aware of …
As in any other relational system, there are 3 types of relationship 1:1, 1:n and n:n.
The main issue is that many systems (for instance Core Data) use inverse relationships to ensure data integrity (and for speed of lookups), but Parse only requires one way relationships. The upshot of this is that when syncing, the client library needs to create any inverse relationships. In practice, I found it easier to use Cloud Code to set up the inverse relationship with the afterSave hook. Generally, though, this is a real PITA!
I've done a few data migrations with the Parse Data Browser - from one account to another, duplicating for testing etc, and it is quite simply horrible.
The export is, on the whole, pretty good - it allows us to get a fairly good output of whatever data is in the tables.
That however, is the problem, its only data that is exported. I suspect that because Parse's data storage is supposed to be schemaless, when the data is exported, it only exports the data and not any sort of schema - so for instance, if you have an empty table, the exported JSON is also empty.
This is a big issue because Parse classes do have ‘schemas’ - there are columns, with types which may well match those in your client.
So for getting your data out of Parse, it may well suffice, but if you're doing that in order to migrate it or duplicate it, its really not adequate.
Import however is a whole different story.
Cloud Code is really useful and opens up a huge number of possibilities for working with Parse but its a real ball-ache to work with!
Although this might seem like a big old whinge, I‘m posting it because I think Parse is a great product and it, and its ilk, represent a huge boon for developers who want to focus on the app they’re building and not the infrastructure that supports it.
Cloud code certainly allows us to work around some of the issues, but there are still a number that make working with Parse more difficult than it should be. I really hope that we see these things resolved soon, so I can get on with just building apps and not working around issues.
]]>If you’ve never used Scratch, it’s a program that allows you to code by snapping blocks together, with blocks shaped to only fit into certain spaces. Stencyl builds on this concept, and introduces elements to make creating games easy, such as physics (Box2D), animation and level building. It also comes with a number of sample games covering the main types, so you can start with one of those and customise it as you like.
My experience so far has been really positive. I’m using the Beta version, so things aren’t quite as smooth as they will be, but the developers (and other users) are very active on the forums and have sorted out my problems very swiftly. I was able to get a working space invaders type game up and running within a few hours, working from the tutorial, and then moving on to adding more complicated behaviours to put some more fizz into the game. It’s this ease of use that really makes Stencyl worth using, getting you past the tedious set up that normally goes into making a game and straight into doing the fun stuff.
The main paradigms are Actors, Behaviours, Groups, Tiles and Scenes. Actors are anything that require behaviours, so these could be the player character, enemies or things like platforms or doors that require special treatment. Behaviours are the meat of the game, and cover all the things that an Actor can do, for example, Walk, Jump, Attack and so on. These are reusable between Actors, so you can simply assign the behaviour to anything that needs that action. You can also reveal properties so that they can be customised, so you might reveal a height property for your jump behaviour. Groups are used to provide separation between Actors, so you might have Players, Enemies, Platforms, etc. as Groups. Behaviours can check whether an Actor belongs to a particular group and customise its actions based on that. Groups are also used for collision detection, and you can specify which groups collide with which. Tiles are background or foreground objects, and cannot have behaviours attached, other than whether they are collidable or not. Scenes combine all the previous elements together to produce levels, menu screens and so on.
There are downsides to using a framework rather than coding directly. Although you can write code directly in Actionscript/Haxe, this isn’t encouraged or documented. The method of grabbing and snapping together code blocks can feel a bit clunky at times, especially if you need to make a small change like changing a < to a >. In order to do this, you have to pull out the block, find the new block, add it in, move the arguments from the old block to the new one and then drag the old block to the bin. However, a right click gets you to the most common blocks, and there are dropdowns on the code spaces which give you the blocks you can use in that context, so it isn’t too onerous. There are also occasional glitches, either in the behaviours (although the ones created by the core team are solid) or in the physics engine because it’s not entirely suited to arcade style games. The developers are working on a “simple physics” mode which should hopefully combat these issues in games where the full power of Box2D is not needed.
The main advantage of Stencyl for me though is workflow. Rather than having coders, designers and artists working separately, and the final responsibility of creating a build in the hands of the programmers, Stencyl allows everyone to work much more closely - the programmers can create behaviours and then pass them over to the designers to tweak the values, while the artists can work on the animations and backgrounds, all running in the game directly. Because the behaviours are easy to read, code savvy artists can modify them, and because the whole system allows you to get up and running so quickly, you can get into iterating your game design at an early stage. Anyone can create a build without technical knowledge, so it becomes much easier for each person or team to iterate on their work without having to disrupt the others.
All in all, while it has it’s flaws, Stencyl is proving to be a great framework which provides a powerful and simple way of creating games.
]]>Personally, I think that if implemented well and extensively, this could be huge for iOS development and the utility of iOS as a whole.
From experience working with one of the open-source scene graph libraries out there, this is definitely an area where a well implemented library from Apple could have a huge impact on the development of 3d in games and interfaces on iOS.
Fingers crossed on seeing either or both of these in iOS 7!
]]>I've been using Parse.com a fair bit recently for iOS work, and recently for an iOS/Android/web project.
One of the recent additions to Parse is the cloud code system which allows you to run code on their servers, included in that are a number of modules for interacting with other web services.
By defining a very simple function and uploading it the Parse Cloud, we can do server-side validation of form elements and then send an email using Sendgrid.
Then a super simple javascript application on the client side, embedded in a page of a website and we've got ourselves a contact form!
If we decide down the line to extend it to do push notifications, call or SMS with Twilio, etc, this is all just a matter of adding a few more lines to our CloudCode.
]]>Fix UILocalNotifications; having recently worked on an app which needed to implement reminders (with associated actions), UILocalNotifications was the only real option (I didn‘t want to use push notifications because the user might be offline, and Reminders.app and EventKit don’t allow you to launch straight into your app). The problem is that the granularity of repeats for UILocalNotifications is very coarse, plus there is a limit of 64 per app. I ended up with a solution that grouped notifications into half hour time slots, which worked for that app, but really a lot of pain could have been avoided with finer grained control of repeats and no hard limits.
Git + Storyboards / Xibs playing nice - I like Xibs and Storyboards; they suit the way that I think, and give me a way of prototyping and iterating rapidly through adding real functionality in only a little longer than it takes to do in wireframe. The biggest problem is that they really don‘t work well with SCM primarily because they don’t merge nicely. This is annoying with Xibs, but really hard work with Storyboards which might contain your entire app. I'm not sure exactly what the answer is here, but the boffins at Apple must be able to figure something out!
That's it for today; more to come.
]]>set the rasterization scale (thus ensuring the rasterization is done at correct scale for the device - retina/non-retina):
1 | layer.rasterizationScale = [[UIScreen mainScreen] scale]];
|
or move the shadow into its own layer and adding that as a sublayer.
Both options work - it depends on what your specific use case is, as to which is going to be better for your app.
]]>Music: appears by etc. soundcloud.com/etc-sounds
]]>Part of this is that I'm focussing on other things (mostly native iOS development), partly because the whole landscape is changing; but also because “applications” like Octopress and Jekyll are finding a sweet spot between being dynamic (the site is generated on the fly) and static (everything is hard coded).
By working with a pre-processor, I get much of the flexibility of templates, document fragments etc but end up with a static website which can be served very very quickly.
Using client side scripting (Javascript) to add interactive features, perhaps in conjuction with service providers (like the aforementioned Parse.com), we can have the best of both worlds.
We'll see!
by Andy
]]>the New Era Cube app we developed with somewhat.cc is todays FWA mobile app of the day!
]]>FWA stands for Favourite Website Awards, an industry recognised internet award program and inspirational portal, established in May 2000.
FWA is the most visited website award program in the history of the internet, with over 140 million site visits as of July 2011 (and multiple billion hits to our servers).
]]>
]]>
Watch the promo video here:
]]>The app uses the iPad camera to recognise the labels on 3 different Sainsbury's products, then shows information about those products, and allows users to provide their details for further information.
]]>As the framework has developed through 3.0.x, 3.1.x and now into 3.2.x, each point release (although thankfully not point-point release) has required a significant amount of work to upgrade my codebases; work I can ill afford to be doing. I'm also a bit disillusioned with some of the internals and want something more modular.
So now … Symfony2. I think its going to be a while before I‘m anywhere near as comfortable with Symfony2 as I am with Kohana, but conceptually, I’m happier with the way it has developed, the reception its getting and the design decisions that have informed its development.
We‘ll see; if not I’m sure Kohana will be just as great if I decide to come back. In the meantime, I'll try and blog some of my experiences developing with Symfony2.
]]>