Tag Archives: apple

Mobile site testing overview (Mobilizing websites with responsive design and HTML5 part 9)

Posted on by
4

This blog post is a part of Mobilizing websites with responsive design and HTML5 tutorial. For all posts please see the Introduction post.

After your mobile site starts look complete in a development browser (e.g. desktop Firefox+Firebug combo) then it is time to begin testing it in actual mobile browsers. This blog post gives you introduction and some general tips for mobile browser testing. Each platform (iOS, Android, others) are dealt separately in the future blog posts, so don’t forget to follow.

1. The micro battle field of browser vendors

Like with desktop where you test your site across browsers you need to test the mobile site in different mobile browsers. The testing is important because mobile browsers use different browser engines and different engine versions. Thus, sometimes output differences are expected and you need to iron out the ugliest issues.

The major mobile browser engines are WebKit on Safari/Android, Opera (Presto) and Firefox (Gecko). You luckily could say that mobile Internet Explorer’s market share is so minor that you might want to bother for it currently. Microsoft is constantly improving its mobile browser, but currently it is not in a state to match the competition in feature wise and we’ll look forward to see what Windows Phone 8 will give us.

There exist two popular after market browser (Opera Mini, Firefox Mobile) with their own engines. Opera Mini is a thin client browser and special considerations with e.g. Javascript interaction must be followed to make the sites behave well. Firefox Mobile can be installed on Android devices. There exist several “browsers” in app stores for iOS and Android, but they are simply wrappers around the native operating system WebKit component and do not contribute significantly to HTML rendering bits. Opera Mini, being the most popular mobile browser in the world by “shipped devices” count is preferred in developing countries due to capability to run low end phones, or anything having CPU and battery power. Don’t forget to test on these also.

The good news are that if the mobile browser support CSS3 media queries, as used in the mobilization strategy of this tutorial, then they are likely to have very good support for HTML5, CSS3 and other modern goodies. The fixing and workaround work found during the testing is usually less than what it takes to make the site run older Internet Explorer.

If you need to define compatibility list of browsers e.g. for an offer I recommend use this jQuery Mobile mobile browser grading table. It gives you an overview how “good” mobile browsers are.

2. Accessing different mobile browsers on devices and simulators

If you aren’t a mobile developer you might not have access to a real test device repository. Luckily, the simulators by the mobile vendor themselves are pretty good nowadays and you don’t need to be physically able to access the every device out there.

It is desirable to minimally have one iOS and/or one Android device for testing. If you are targeting popular iOS devices (iPhone, iPad) it’s pretty hard to get around the fact that you need to get a Mac. Apple tools are only for Apple computers, like Microsoft mobile tools are only for the latest Windows 7.

There exist generic remote testing services for mobile phones, but they often are costly and not a substitute for the real thing.

3. No shortcuts to testing happiness

Warning: Do not use browser+<iframe>-based “mobile simulator” or whatever crap web search throws on you.

These so called simulators are usually pitiful attempts to grab web traffic for ad money without actually adding any value to testing. Running <iframe> based simulator in your web browser is simply the same as opening the page in your desktop web browser directly, with the window size shrink.

Shortening URLs

Typing on the mobile devices is cumbersome. Use URL shortening services like bit.ly to shorten your test page URLs, so you can type them in faster on touch screen or keypad.

4. Desktop web browser testing

If you need to alter HTML code or main CSS when mobilizing a legacy website you still want to see that your HTML changes did not introduce issues on the desktop browsers, especially older and problematic Internet Explorers. Here are some desktop testing resources, but I’d hope to hear of more pointers and services so please comment.

5. Internet Explorer virtual machines

How to automatize the installation all Internet Explorers on OSX and Linux using VirtualBox and one liner shell script.

6. Remote page rendering services

Please refer to this Smashing Magazine article for list of cross browsing testing tools.

\"\" Subscribe to RSS feed Image Follow me on Twitter Image Follow me on Facebook Image Follow me Google+

Native mobile application development with Plone, WordPress and Python

Posted on by
5

We have just released two mobile applications backed by Plone, WordPress and Python middleware code. In this blog post I’ll tell some background information what we have learnt with mobile applicationand Python development.

mFabrik News – download now for iPhone and Android

Image

Image

1. Why create a mobile application?

The first question is why one rather create a mobile application when the same task can be accomplished with a mobile site? Most people even prefer mobile sites over applications. From a pure engineering viewpoint, mobile applications are usually just glorified RSS readers that embed Webkit and add some native user interface bling bling over it. With an app, you are limiting your target audience, because an application is limited to one platform. Maintaining application(s) and application developers is more expensive compared to a mobile site which few (cheap) PHP junkies can throw together.

But is not always technology or price which matters. Mobile applications have prestige value – having or showing success, rank, wealth, etc. If you have a high quality brand, you probably want to have a mobile application too. When you see the brand logo swinging forth and back in an iPhone application with smooth animation running 60 frames per second, you see that it is a proper placement for the brand logo. The output is more luxury, more carefully planned, and does not look like it was thrown together by few cheap web developers.

There are even rationale reason for going after applications. First, you are in a business of making money. It is a lot of easier when the platform itself is offering you a payment solution without a monthly fees (iTunes payment). Other good reason is that there exists interaction between the application and your content beyond the browser window.  You can push messages or do things even if the user is not on your site (see more information about the push solution we implemented below).

2. Mobile application development and Python

As most of this post readers are probably fellow Python developers, here are some thoughts specifically aimed for them. Python itself is not a very good alternative what comes to mobile application development. Though, the application itself may not contain Python code, Python still shines on the backend side of the things. For example, we’ll hope to publish an example application using Google App Engine in the near future.

The only future proof platform where Python is 1st class citizen for building applications, is Nokia’s Meego with its Pyside and Qt bindings. Unfortunately Meego doesn’t have any shipped handsets and looks like it never will.

Android has script bindings, but they are not good enough for real application development, as interaction with the native platform happens over TCP/IP sockets. However, Android has seen some recent exciting development from PyPy project, possibly enabling native Android development for Python in the future.

iOS with Python could be a go, now when Apple has lift ban on interpreted languages. I haven’t heard anybody doing it yet, though. CTypes had some problems long time ago regarding run-time generated code for Python bindings.

Python has also a port for Series 60 (Symbian) – don’t go there if you are not prototyping. It is good platform for students for  playing around, but unfortunately it has never been considered as serious development environment by the handset manufacturer. You have tons of headaches if you actually want to release a product version of your application.  Nokia N900, soon supported. is better prototyping platform for Python than Series 60 as you get full Debian userland.

3. Mobile application development and wrappers

There exist various wrapper technologies which help you to wrap your HTML5 application to a native application shell. With simplistic APIs provided through Javascript bindings, you can access a limited subset of native platform APIs. Wrapper technologies are mostly aimed for web developers, who do not have any experience on application development and they might want to skip the learn experience of native development.

Wrapper technologies do their job and produce decent apps. But if you are a Python developer I recommend you skip the wrapper step and build your own native user interface and embed Webkit yourself. Designing an user interface is much is easier with Apple’s Interface Builder or Google’s  Android tools than with half-baked Javascript bindings. The fact that you are actually able to insert a real breakpoint into your code is itself worth of skipping wrappers. If you already are a Python developer you already know at least one real programming language and mastering Objective-C or Java should be an easy task for you.

Webkit itself has bugs. You will regularly hit obscrure bugs when the amount of  Javascript and CSS code grows. In the worst cases Webkit just dies under your application without a way to debug the problem – sometimes without a workaround available for the problem. This means dead end for your lovely application. You don’t want to end up to this situation. So, just to have more low level control, using native tools is good.

4. mFabrik News application

Image

mFabrik News mobile application allows you to follow the latest news of mobile and web development, produced by our hacking team. The applications source the news from our Plone based web site and WordPress blog (which you are currently reading). It uses special RSS streams prepared with our Web and Mobile multichannel publishing solution: news images are optimized for mobile device screens using a handset database (Wurfl) and some other HTML preproessing is done to make the posts look better in embedded WebKit. Processing is done using mobile.sniffer and mobile.htmlprocessing Python packages which are generic Python packages and should be usable in various environments, including App Engine.

iOS mFabrik News application has push notification support. Android doesn’t yet implement push solution, but it is coming for Android 2.2 handsets.  Please see the earlier blog post how we use Apple Push Notifications with Python.

Download, give the apps a spin and report any feedback! (direct links at the beginning of the post)

We may or may not release the source code of the applications, depending if anybody thinks they actually would find it useful.

\"\" Subscribe to RSS feed Image Follow me on Twitter Image Follow me on Facebook Image Follow me Google+

Apple push notifications (APN) with Python

Posted on by
1

We have created a middleware service which inputs RSS feeds and outputs Apple Push Notification. This allows integrate push notification support for your existing content management system easily. This blog post should give you some ideas if you are planning to create similar services.

To have the über-experience of customer engagement with mobile push notifications you need

  • A mobile application (iOS, Android 2.2)
  • RSS feed to notifications middleware server (our solution)
  • RSS feeds themselves
  • Windows/UNIX server running the middleware

1. How it is put together

Tornado web server is used to handle incoming HTTP requests in scalable manner.

feedparser library fetches RSS feeds and processes them to client notifications.

BitReader (post, source) library is used to create messages to interact with Apple push notification service (APNs). The protocol is bit based protocol running directly over TCP/IP. Apple service has been designed to handle high volumes of traffic – it does not use anything like stateless HTTP to waste bandwidth.

Django models are used to store the state of each individual subscriber. Django’s ORM abstraction allows us to use the same middleware for small distributions (< 1000 clients, SQLite database) or big ones (millions of clients, MySQL database). The stored state information includes the subscriber id and the current badge number – the red circle on the app icon showing the count unread posts. When the application is launched, it can decrease its badge number by doing a HTTP call to the server.

Django settings are used to put together required certificates and whether the application is run in sandbox mode.

2. Walkthrough

There is a core IO loop, running in a separate process, called stream observer. This loops updates fetches RSS feeds’ status and passes updates to Tornado server over HTTP.  With this arrangement, any HTTP capable client can send push notifications.

Tornado handles incoming updates, updates the related subscribe status – how many unread notifications, etc. through exposed Django views. The notification is formatted according to the variables available on the subscriber mobile platform. In Apple’s case, the notification message gets title, badge, sound and a launch image. Payload is checked against hard 256 byte limit.

Then the payload is pushed to Apple servers over TCP/IP protocol. SSL certificaties needed.

A subscriber is registered  when the mobile application is launched. The application asks a subscriber id from Apple servers. Then, this subscriber id is delivered to our middleware over normal HTTP call.

The middleware also handles feedback service which gives you list of devices which have unsubscribed from your service. This way you can cut off notifications from unsubscribed clients. This is also done using BitReader and TCP/IP.

3. Future

The architecture is built so that different push backends can be included in the service. Android support is on the roadmap and we probably will have Blackberry and Meego support (when/if Nokia announces such a service).

We have currently tested this solution with RSS streams from WordPress and Plone.

We may release source code when it’s ready.

4. More info

\"\" Subscribe to RSS feed Image Follow me on Twitter Image Follow me on Facebook Image Follow me Google+

Apple MobileMe Free Trial – IT’S A TRAP

Posted on by
1

Watch out for Apple’s MobileMe service. I wouldn’t have believed Apple uses so cheap business tactics as they advertise “Free Trial” but end up charging your credit card for 79 €.

A credit card is required to start your free trial. After your trial ends, your card will be charged an annual subscription fee of €79.00*. Don’t worry, to avoid these charges, you can cancel your subscription online at any time during the trial.

Bastards! Don’t go for MobileMe. YOU SHOULD WORRY.

\"\" Subscribe to RSS feed Image Follow me on Twitter Image Follow me on Facebook Image Follow me Google+