About a year ago I updated the OS on my iPad without paying enough attention to the ramifications, as a result I a significant amount of music that I had loaded on without syncing to a PC was lost along with several apps that I had downloaded from the AppStore.
This week I was surprised and delighted to find that upon upgrading iTunes on my PC to the latest version, I am now able to see my previous purchases and re-download them from the cloud.
In a few minutes time I hope to re-discover the timewasting delights of two of the Angry Birds series that I have somehow managed to live without for the last 12 months, along with some games that I had purchased but not tried out.
Now I just need to figure out a way of transferring the dozens of albums of music that I have on a PC on the other side of the planet...
Showing posts with label iPad. Show all posts
Showing posts with label iPad. Show all posts
Saturday, 22 September 2012
Wednesday, 13 April 2011
Technical challenges streaming data over HTTP
I have recently been exploring options for enhancing the functionality of an existing website by integrating some streaming data feeds.
In the interests of making this functionality available on a wide range of devices (read iPads and iPhones as well as PCs) I would like this to be achieved without Flash or any other proprietary plug-in technology.
So, my old friend and foe Javascript is the lead candidate for providing the functionality on the client side.
Almost every article and blog post that I have read on the subject emphasises that client side polling is not appropriate, and that instead a continuous connection must be kept open between the web browser and the http server.
To avoid some of the challenges posed by Javascript's cross site scripting (XSS) security restrictions we would ideally push the data feeds out from the same domain name as the page that contains the feeds. For less data intense AJAX functionality this was made possible by hosting the servlet engine behind apache httpd.
Historically the way that most http servers have served their content involved dedicating a thread or process to serve each incoming request from start to finish. This does not scale well when incoming requests need to hold a connection over a prolonged period of time, so alternative approaches such as Comet have been implemented.
The Tomcat implementation of Comet is not supported when Tomcat is hosted behind apache httpd over AJP.
I was considering keeping the data serving system physically separate from the serving of HTML content anyway, so this restriction is just giving a friendly push to try using a separate sub-domain.
In the interests of making this functionality available on a wide range of devices (read iPads and iPhones as well as PCs) I would like this to be achieved without Flash or any other proprietary plug-in technology.
So, my old friend and foe Javascript is the lead candidate for providing the functionality on the client side.
Almost every article and blog post that I have read on the subject emphasises that client side polling is not appropriate, and that instead a continuous connection must be kept open between the web browser and the http server.
To avoid some of the challenges posed by Javascript's cross site scripting (XSS) security restrictions we would ideally push the data feeds out from the same domain name as the page that contains the feeds. For less data intense AJAX functionality this was made possible by hosting the servlet engine behind apache httpd.
Historically the way that most http servers have served their content involved dedicating a thread or process to serve each incoming request from start to finish. This does not scale well when incoming requests need to hold a connection over a prolonged period of time, so alternative approaches such as Comet have been implemented.
The Tomcat implementation of Comet is not supported when Tomcat is hosted behind apache httpd over AJP.
I was considering keeping the data serving system physically separate from the serving of HTML content anyway, so this restriction is just giving a friendly push to try using a separate sub-domain.
Monday, 4 October 2010
Flash or no Flash?
While working with graphic designers on various websites in recent years the decision of whether to include Flash or not came up on a number of occasions.
Things progressed from, "Let's not", to "Okay, as long as we have some Javascript to serve alternative content", to "Flash is so prevalent, alright you can use it for content that won't need to be maintained by the customer"
Now that the iPhone and iPad and various other mobile devices are moving up in the ranks of common browsers Flash may have to retreat again.
HTML5 support might make this less of an issue, but I don't particularly fancy moving to having multiple versions of presentation based on browser type (User Agent header supplied in request).
Things progressed from, "Let's not", to "Okay, as long as we have some Javascript to serve alternative content", to "Flash is so prevalent, alright you can use it for content that won't need to be maintained by the customer"
Now that the iPhone and iPad and various other mobile devices are moving up in the ranks of common browsers Flash may have to retreat again.
HTML5 support might make this less of an issue, but I don't particularly fancy moving to having multiple versions of presentation based on browser type (User Agent header supplied in request).
Mobile development experience
Even before acquiring my iPad (today) I have been thinking more seriously about getting into developing for mobile platforms.
I have been along to a couple of presentations about Android and cross-platform development for Android and iPhone so have picked up some useful ideas.
Since I don't have a Mac I think I will have to target the Android platform first.
Hopefully the development won't involve as much trial and error as was required for the Windows Mobile development work I did for Pocket PC applications a few years ago.
Anyone remember the HP iPAQ? That's the sort of platform that we were targeting back then - along with the early generation of 3G phones that came with Windows Mobile.
The .net Compact Framework didn't really have enough ways of hooking into the capabilities of the device back then, so we had to resort to integrating third party Visual C++ DLLs to get at the text messaging and GPS capabilities for location based services.
I have been along to a couple of presentations about Android and cross-platform development for Android and iPhone so have picked up some useful ideas.
Since I don't have a Mac I think I will have to target the Android platform first.
Hopefully the development won't involve as much trial and error as was required for the Windows Mobile development work I did for Pocket PC applications a few years ago.
Anyone remember the HP iPAQ? That's the sort of platform that we were targeting back then - along with the early generation of 3G phones that came with Windows Mobile.
The .net Compact Framework didn't really have enough ways of hooking into the capabilities of the device back then, so we had to resort to integrating third party Visual C++ DLLs to get at the text messaging and GPS capabilities for location based services.
Sunday, 28 March 2010
iPad might be worth a look after all
I'm slowly coming to the realisation that the last few books that I have purchased have been PDF files rather than physical paper.
Once the hype dies down and the inevitable technical version 1 issues are ironed out I may take a look at iPad.
Once the hype dies down and the inevitable technical version 1 issues are ironed out I may take a look at iPad.
Subscribe to:
Posts (Atom)