Why should I develop native mobile application (sometimes)?

When we faced the question about if we should develop a web mobile application or a native mobile application, there is no universal answer (although sometimes, reading some articles, it seems there is one). When we begin a new development, first of all we must begin with a requirements analysis and functionalities that we are going to implement, and based on these we can make decisions. Just like when an architect designs a building, does not arise if there are good or bad materials or techniques, the architect just think if these materials or techniques are suitable for this particular work. We should think about every developmet independently and carry out a specific analysis for the application we will develop (otherwise the bogeyman will come and he will take away all our work, developers

who worked during the software crisis will tell us that this is true).

The purpose of this post is to analyze the case of developing a mobile application for Sakai OAE, of course, this is my analysis and I will be happy to rectify any mistake or any approach that can be wrong. Anyway, if you are interested in something more generic, google is our friend, simply search for "native apps vs web mobile" and you could spend all evening reading tons of articlees about this subject.

During this GSoC, two mobile applications are being developed for Sakai, and each one follows a different approach. I sincerely believe that both decisions are correct. I'm sure that Kasun Lakpriya and Steve Swinsburg who are developing the web-based mobile application for Sakai CLE, will give you plenty of good reasons why a web application makes sense to Sakai CLE. I'll focus on Sakai OAE.

Sakai is a young web application OAE, based on well-recognized standards, such as ajax or json, its design completely revitalizes the user experience by improving the workflow for both teachers and students. It is a highly scalable application that is developed following best practices ... It is definitely a really cool a web application. In fact, thanks to the hard work being done by the ux team, we can browse the web application using a mobile device and the application still will look really nice. So, in my point of view, since we have a good web application that with small changes may well be a mobile web application, it makes more sense to try to take advantage of the possibilities that native applications will give us.

And what these possibilities are? Well these are some of them that we could use in Sakai OAE, but certainly these aren't the only ones:

• Connectivity (Off-line mode): Although it's becoming less common, not all places have a good Internet connection, in Spain from where I write at least this is so. And web applications need, obviously, Intenet connection to work (even though we can achive some things with html5 and Google Gears). So being able to have the application running all the time is an advantage, we won't lose an alarm that warning us a deadline of a job, or stop reading some content because we don't have an Internet connection.


• Improve the user experience: Native applications, in general, improve the user experience, not only by the performance they can achive, but to use elements of the user interface of the device itself, although, of course this can also be emulated. It is also very interesting the possibility of having the application running in the background and receive certain notifications, as twitter apps do.


• Device-based caching:Certain information could be store encrypted on the device itself, which is very useful for improving the user experience, not forcing him/her to introduce the same data each time.


• Using the device features: This property could seem a bit strange in case of an educational application, but if you think about it is not. For example, when a teacher creates an activity, he/she could not only tag the date and time whe the activity will be done, also it is possible to introduce aGPS address indicating the place where the activity is take place, which is really helpful if we think about field practices, especially large campus or for students with no spatial orientation (this is my case). And surely we could imagine a lot of creative utilities using phone services such as the agenda or the camera. Why should we limit it?


• Discoverability: It's really easy to find an application in the market / app store.


• Performance: This is, in my opinion, the jewel in the crown of native applications. We can develop threads, use devices notifications, and make the application run in the background... And in the case of our application, where normally users turn on the app early in the morning when they arrive to university and they won't turn off until they go home, this is a very interesting feature to exploit.

Although there are also mobile applications features negative, we can see the positive side of these (or at least, do not consider them so negative)

• Automatic Updates: Web applications are updated automatically, while in the case of native applications we should upload them to market/app store and wait util the user updates them. This is initially a point for Web applications, but from my point of view, this is not so negative for Sakai OAE. The mobile application of a large university, must be stable and not constantly updated unless absolutely necessary (I'm thinking of a security bug), so we shouldn't worry too much.


• The censorship of the market/app store: I have write market/app store because I don't want to not arouse suspicions, but really where the applications pass quality tests and can be rejected is at the appstore. Again, this seems quite negative, but an application is rejected by quality issues primarily (or duplicate a service of IOS, which is not the case), which obliges us to work hard on the quality of the application, and Apple is not particularly ambiguous on how we should develop applications. If we'll see it this way, I honestly do not think it's an inconvenience at all.

And since not everything could be so beautiful, there are features that are inherently negative (if you can see a positive side please tell me!):

• Reaching the audience: Although Android IOS and monopolize the market for mobile devices, these are not the only platforms, which makes our mobile applications fail to reach the audience. But as I mentioned in the introduction, Sakai OAE is a good web application that can be accessed from any mobile browser.
  


• Maintenance: This really is a handicap. A native application implies that we must develop at least two projects for IOS and Android, and the rise of Windows Phone makes me think than maybe for this one too. This multiplies the cost of development and maintenance. I'm developing it for IOS and Android, and I suffer the problems of implementing functions in one platform that are completely different in the other, I can not deny this. Some months ago I was naive because I though that the development and maintenance costs would be lower since both apps are restful applications and the same web services are called. Anyway, Sakai community is big and great and I think the advantages outweigh the disadvantages.

I don't mean that web applications can't work as native applications. And every day we will find new frameworks to simply the work and get better performance.

To summarize, I don't think there is no good or bad answer about what kind of app develop. This is my analysis, and of course there are many nuances to all the features I've listed, I won't be surprise me if I'm completely wrong in more than one point, so I encourage you to leave me any comment with your thoughts and talk on here or IRC #sakai where you can find me as AdaHopper.

Mid-Term Report

Its been amost a month and a half since GSOC started and this is the mid-term report for the 1st phase of the project which is writing all the basic WebDav methods.

I am glad to say that I have been able to do that without encountering many problems.As I described in my proposal I used milton to rewrite the webdav methods.

Milton is an opensource library for adding webdav support for an existing web application.

Integration

The most common way of using milton is to add the MiltonServlet to web.xml.Milton is agnostic about the nature of the data. we can simply implement the interfaces needed for it to locate the resources.

The central concept to Milton is Resource so we extend the resource interface

for each HTTP method with methods to support that method .We can choose which http methods to allow on your data by choosing which Milton Resource interfaces

to implement.Thus a class which implements a resource will contain methods for GET,POST,MKCOL etc based on the interfaces we implemented.

Its completely appropriate to not implement any method if we do not want to support the method.

Progress

At first I thought milton was confusing but after some great support from the author(Brad Mcevoy) I found that milton is very easy to use.

I created 4 classes 3 implementing the milton interfaces and 1 helper class.The first thing that I did was to implement the File(SakaiFileResource) and Folder(SakaiFolderResource) Resources which represent

a Resource and a collection respectively.Then I implemented the ResourceFactory(SakaiResourceFactoryImpl) for finding the File and Folder Resources from the URL.

We take the path in the url entered by the user and check if it represents a resource or a collection based on this it returns instances of SakaiFileResource or SakaiFolderResource.

And finally I wrote the SakaiDavHelper Class which contains accessory methods.

The last step is to add the MiltonServlet to web.xml.

As of now I have written all the webdav methods using milton but without authentication (its a bit tricky with milton and the current dav code is confusing).The final

step is to add the milton jars to our pom.xml and we are good to go.

In my proposal I mentioned the rewrite of the nested classes DirContextSAKAI,ResourceInfoSAKAI and SakaidavServletInfo This proved unnecessary as milton

is resource centric and all the required information about a resource or a collection is contained within the file and folder objects(The function gerResourceInfo() does the job) thus eliminating the need for the rewrite.

Finally Thanks to my mentors Anthony Whyte and Seth Theriault for their support.

First month report in GSoC

Well, it's been a full month (and a little more), since I started working on coolest grant I know: GSoC. So it's time to make a properly report about project status, mainly to keep up to date with developments in the Sakai developer community.

I can only begin by thanking the work done by my mentor, Carl Hall, who patiently read my long post and still more patiently answer all my questions. Thanks Carl :)

I wish more things were finished at the end of this first month. But as recently I completed an important milestone, so I can be positive reviewing reached objectives above remaining objectives. Moreover, it's normal in the first stage takes a little bit longer development because I had to learn the technologies we work on the project (Objective-C, I'm looking at you, weirdo language), refresh the knowledge stored in layers of dust in my head (I'm sorry I left just Android), inquire about Sakai OAE (beautiful breath of fresh air I am sure will revitalize Sakai) and finish my exams (the GSoC starts early for European students).

But no excuses, let's focus on the things that if I achieved which really matters.

Sakai OAE: thanks to jar file that Carl gives me, put into operation a local version of Sakai has been trivial. So I could concentrate on reading the documentation and play a lot with Sakai trying to understand the basic operation of the application. The existing documentation is not extensive, but is compensated by the high availability which the project developers have to answer questions. If you have any problems, I would recommend that you to pass through the irc channel #sakai, there are always good people willing to help, or the mailing list sakai-dev,although the specificity for Sakai OAE is sakai -ui-dev. I have also found very useful documentation on quality tests because I have allowed to understand the user's work flow in Sakai.

Mock up: in the presentation of the project I've already showed some mock ups of the application and during this time we have been working,Kasun Kakpriya and I, trying our two mobile applications were most similar, so the user experience will be as similar as possible between the two mobile versions of Sakai CLE and Sakai OAE. We agreed in the work flow of the application, so that the two applications would have the same work flow and differ in some of the screens. This gives us flexibility to offer the best mobile version of each of the versions of Sakai and maintain the user experience. Moreover, regarding the decision that what mock up I will implement , I am still awaiting a answer from the design team Sakai OAE, but I preferred to continue developing the inner part of the application and wait a little bit longer to UI team could answer me. So, if you are part of the design team, would be really nice to get some feedback (thanks!).

Skeleton application for Android : it is ready the skeleton of the Sakai application on Android. It is a tiny skeleton for now. It has basically the view with the log in and a second view where he arrived after identifying the user. Created packages are also organized by the java classes as well as the internationalization files.

Skeleton application for iOS: idem in IOS. Although , as I said in the introduction: window management in IOS is very strange. Maybe it's because I already have experience in Android and it takes me more work to switch, or because management is really weird (I'd bet on the latter ;) ).

Authenticate users in Android: this is the milestone I have achieved. Users can now authenticate themselves sending its credentials. _Carl Hall and I, studied the possibility to authenticate users using the OAuth protocol, even it is a standard that is spreading rapidly, the implementation of this protocol is beyond the aim of GSoC. Also Nakamura's team is working on this. Nevertheless, the application is ready to change an authentication method for another one, so after the change will be not complicated.

I had this post ready for two weeks, so sorry for the delay. As you will understand the application development has advanced. If you will like to follow the development daily I will suggest to follow the repository: https://bitbucket.org/mrs.hopper/nellodeeoae

I hope you are interested about the project, I would like to hear some feedback. And if you have anything to ask or suggest me, plese do not hesitate.

Sakai CLE mobile application with phoneGap

In my previous post I mentioned how to setup the working environment and useful tools we can use to develop mobile applications using web technologies. Today I am going to present what I learnt during the past few weeks and the status of the CLE mobile application at the moment.

As discussed with my mentor, Steve Swinsberg, the basic requirements of the CLE mobile app. are as follows for the first version also listed here and the UI flows can be found here. (Screens v1.0.1) 

User login

User enters user details to enter the system.

 List of sites

s/he will be directed to a list of sites that they are in (assuming credentials are correct)

 List of tools

User selects a site will navigate them to a tools list of the selected site. Here they can see how many new announcements, assignments and etc are there at a glance.

 Mobile version of each tool

Once they select a particular tool they can view the above details in detail. This will hopefully be a read only tool for the first version of app.

Current status  

List of sites and tools for a selected site done.

Both this screens are rendered using JSONP feeds of my local host because JSON feeds did not work due to domain issues. Please find the code here and please add your suggestions.

Try out this in your emulators with phoneGap

If you want to run this in your emulator what you have to do is to create a phoneGap app. following their tutorial and add sites.html to assets/www directory.

To add JSONP support for your local sakai instance you can do the following change to core-providers in entitybroker and deploy *only* it in tomcat.

Checkout entitybroker trunk if you don’t have,

•  svn co https://source.sakaiproject.org/svn/entitybroker/trunk/ entitybroker-trunk
•  then in, core-providers/src/java/org/sakaiproject/entitybroker/providers/

edit the classes where it says:

add Formats.JSONP to the end      

• mvn clean install sakai:deploy (from entitybroker pom level)
•  re/start Tomcat.

Yeah that’s it! Now you have JSONP support.

Here is how to add a customize callback function,

That's it you should be able to see above screens. :-)

This is a useful place you can try JS, CSS, HTML http://jsfiddle.net/. Here we don't need to put all code just the snippets work nicely for example http://jsfiddle.net/HQK5w/6/

Thanks to my mentor, Steve Swinsberg, for the support and directions.

As always waiting for your comments.