I’m hanging out at a coworking space in Berlin-Kreuzberg called Co.up
I like the vibe of the place a lot. I’ve been very focused the days I’ve worked there near to a bunch of developers and designers working intently on their web and mobile projects. A couple of times in conversation I’ve tried to summarise my project for these digitally literate coworkers.
I typically mumble something about ebooks and interactive mobile content and digital popup books. It’s easy to call it an iPhone project, but I’ve only spent 2 out of the last 10 months on iOS development, so from my point of view it’s mostly somewhere else. It’s a … platform. Or something. My summary of it changes depending on who is listening, naturally.
I haven’t previously laid out here all the software components of the picklets platform. This summary of the picklet platform technology stack explains the range of software I spend my time on.
picklet-export is a github repo
Python on App Engine. A web app using the Django framework running on Google’s scalable server infrastructure. The advantage of this backend is that I never have to do server management. Ever.
picklet-player is a github repo
Python on App Engine. The same backend app as the builder, handles in-app purchase transactions from the iOS client. All connections are over https, unlike the builder interface. It should be RESTful but it’s not that clean.
PHP. The picklet delivered from the store to the Picklets app is a zip file with a structure borrowed from the EPUB standard. To generate this zip there is a php script that runs on a MediaTemple GridServer host.
Objective-C. The reader component is called Picklets, and is a native app for iOS. Essentially a shell for discovering and delivering zipped web app content. In exchange for money.
Summary of the summary
I have a vision and what often feels like the minimum level of competence required to realise it. And I have a couple of months before I need to get a job. So let’s get on with it, oder?
Offered here without much comment is a short video showing what Picklets for iPad is looking like at the moment. It shows a list of mock content from the Picklet Store (on my laptop). It displays the selected picklet content either near-fullscreen in portrait orientation, or side-by-side with the store list in landscape orientation.
This is going to be great for Content Discovery or ‘getting prospective reader/buyers to actually look at stuff’.
Picklets: they’re not just for Christmas.
Had a happy day of coding on the couch here in Arnhem, integrating Jim Dovey’s AQGridView, as used in the excellent Kobo ebook reader for iPhone and iPad. Yesterday I wasn’t sure how much of this I would be writing myself. Very pleased to get this far with the iPad interface so quickly;
The other thing I nutted out was using separate startup images for landscape and portrait orientation and matching it to the background image on the running app. It’s not really clear in the video, but it’s there.
The picklet cover thumbnail images are just placeholder white rectangles, but the handling of actual cover images is ready to go. Pictured is where I left my Photoshop mockup of this bit of the iPad interface yesterday. In my mind I can see how it moves, even here.
I wanted to share an image of what I’m working on. It shows a picklet called ‘What Goes Around’ that isn’t a real picklet, just two panels of rotating text that I’m using for development. The picture shows the same picklet content, served from the same URL — one in a browser at 320×480 and one on an iPad in the Picklets app at 640×960.
The big green button at the top of the screen is what I think of as the ‘call to action’ button. When viewed on the web, the call to action is ‘Get the Picklets app’ and when the picklet is previewed within the Picklets app the call to action is ‘Install’. This is the trigger for in-app purchase. This is how the author and the developer get paid. It is important.
The third scenario is when the reader has installed the picklet. Then the call to action is ‘Share’ and I’m still working out the details of that, but it will involve the twitter and the facebook and possibly some secret Bonjour service discovery.
It’s a beautiful day in Holland.
This week I’ve been doing some fine-tuning work to make it possible for the first picklet, The 3 Baddest Bandits of the Wild, Wild West, to get out the door and find an audience. It’s been a slow, frustrating week of development but rather than not talk about it, here’s a summary of what went down.
A picklet is constructed from this set of exported images. Ultimately they are rendered on the iPhone/iPad by the mobile version of the WebKit browser engine. This software won’t display an image if its dimensions exceed 3x1024x1024 pixels. I have added a test in the export script to ensure this limit isn’t exceeded.
The Picklet Builder web application runs on Google’s AppEngine platform and stores each image file as a BlobProperty which has another constraint that the stored file must be under 1000000 Bytes in size. I added a test in the script for this limit.
The export script will no longer save a Photoshop layer to a PNG if the file would be too big for iOS WebKit to display, or too large a to be stored as a BlobProperty on AppEngine.
The picklet author sees feedback about the layers that have not been saved to files and can address any issues straight away.
To review a picklet on a device the author creates a picklet ‘draft’. This process involves copying the current picklet structure (a JSON representation of the client-side data model) and caching the current state of the all required image files. The files are copied from the author’s Dropbox/Public folder to BlobProperty fields in a DraftBlob model.
The initial implementation required each image file to be copied for each draft created. In practise the overhead of transferring 50MB of image data for each created draft became a bias against quick iteration of drafts. To improve this I’ve modified the process to store the image file’s modified date, and only copy the file if it has changed since it was last cached.
Additionally I’ve changed the way the image cache function is called so it can happen while the author continues to work in the builder app, or even in case the browser is closed. I’m using the AppEngine Task Queue API with a ‘chained’ task that checks a single image url and caches the file if necessary, based on the file’s ‘modified’ timestamp.
The author now has access to a draft creation task log message, which is emailed to the author when the draft is ready to be reviewed, and includes status information for each image url processed. Currently this process checks that the image is under the 1 MB limit for storage. Missing image files are also indicated in this log message.
Next week I hope to be back in XCode land working on the reader app called Picklets. The big thing remaining to implement is the interface to Apple’s iTunes payment validation framework, StoreKit. That’s how we all get paid and make this project into a sustainable publishing platform.
- October 2012 (2)
- August 2012 (2)
- June 2012 (1)
- April 2012 (5)
- February 2012 (2)
- November 2011 (1)
- October 2011 (1)
- September 2011 (2)
- August 2011 (4)
- July 2011 (5)
- June 2011 (4)
- May 2011 (4)
- April 2011 (9)
- March 2011 (7)
- February 2011 (6)
- January 2011 (1)
- December 2010 (3)
- November 2010 (5)
- October 2010 (7)
- September 2010 (10)
- August 2010 (2)