TagDevelopment

App Interface – Example of HTML Generation from XML and XSLT

Following one of my last posts “App Interface and Data Update with UIWebViews, XML, XSLT and HTML” where some readers requested me to post an example of this method for rendering/generating HTML from XML and XSLT files.

Due to the lack of time from my part, I’ll not post the iPhone/iOS code but only the XML and XSLT files, to help those guys who asked for that. So, here it goes an example consisting of 2 files which can be rendered on almost any current browser like Firefox, Safari or Opera (it doesn’t worked on Chrome for me, don’t know why).

To try this example, just download the following 2 files:

Then open “scorers.xml” with one of the refered web browsers or simply click directly on that link and you should see in your screen the rendered HTML:

This sample code snippets were extracted from our South Africa 2010 Soccer Scores app which you can still download from the App Store [http://itunes.apple.com/pt/app/south-africa-2010-soccer-scores/id379206383?mt=8] and see how this technique working on a real app.

Now to integrate it in your iOS app, you only need to create an UIWebView where you’ll present it. That’s it! 🙂

As usual, your comments/suggestions are welcome…

JSON vs XML – Part 1: Data Size

In this test to compare XML vs JSON files data size, I transformed a sample of our XML data files to JSON, and I’ve obtained the following results:

File Name XML Size (bytes) JSON Size (bytes) Difference (bytes) Difference (%)
groups 6.218 3.379 – 2.839 -45.6 %
matches 14.541 8.823 -5.718 -39,3 %
scorers 1.250 652 -598 -47,8 %
TOTAL/Average 22.009 12.854 -9.155 -41,6 %

Well, after this first experiment it seems that I can save about 41,5 % on my data size if I change from XML to JSON files.

But wait! And if I reduce my tag/field names’ length to only 2 characters long?

Here are the new results that I obtained after that change…

File Name XML Size (bytes) JSON Size (bytes) Difference (bytes) Difference (%)
groups 3.444 2.934 -510 -14,8 %
matches 8.189 7.154 -1.035 -12,6 %
scorers 756 556 -200 -26,5 %
TOTAL/Average 12.389 10.644 -1.745 -14,1 %

Well, that size difference becomes reduced from near 41,5% to about 14%! It seems that with JSON I can save at least almost 2 KB per App update.

If I have 1.000 updates/day it gives less 2 MB of bandwidth which is perfectly negligible.With 1.000.000 updates/day it gives 2 GB/day, which becomes about 60 GB/month. It’s true that can save me some bucks if I’m paying a non unlimited bandwidth hosting service. But maybe it isn’t sufficient to make me change my App, specially if it doesn’t will make my App to be implemented faster and run significantly better.

By the way, until I publish the next post “JSON vs XML – Part 2: Parsing and Display Speed“, I recommend that you read an interesting article from Nicholas C. Zakas, which I found among many other articles about XML vs JSON: “Is JSON better than XML?“.

It compares several aspects of those two technologies in a succinct way.

Note: This is the first post of the “JSON vs XML – Data Size, Parsing and Display Speed” set.

JSON vs XML – Data Size, Parsing and Display Speed

In my previous post “App Interface and Data Update with UIWebViews, XML, XSLT and HTML“, I’ve written a little bit about how I have used XML to dynamically update and display our App’s data.

Following that, now that I’m preparing a new similar App, I’ve read lots of stuff about JSON and about JSON vs XML on the web, which is making me to consider the change of XML by JSON.

Many people argues that JSON is better than XML but that’s not clear and it seems that it depends a lot in what we need to do! Well, I know that’s not something new, it’s what happens most of the times when we’ve to choose some technology against other(s).

But I want to choose the “best” for my case, since I have plans to port this new App at least to Android OS and maybe to Windows Phone 7. And if that choice can reduce my total work in those platforms, it’ll be an important choice.

In general what I’ve seen is that XML is largely supported in all common browsers and in those mobile platforms. JSON is relatively new, however it’s becoming supported almost everywhere but mostly without native parsers.

That’s the case with iOS and WebKit (Safari’s engine). So I decided to do some previous experiments…

Since this article is growing a little more than I preview, I’ll publish the results of my tests in the following posts:

App Interface and Data Update with UIWebViews, XML, XSLT and HTML

I haven’t wrote almost anything about the development of my first App launched on the App Store: SA2010SS. Now it’s time for a little about that…

I’m picking up that code to reuse it on the next App, which will be similar  but this time, based on the National Soccer League(s) with the addition of one or two interesting features, I hope.

This post is focused on the strategy that I used for our App’s main interface and data updates.

Starting by the data updates, our App gets the data from the server, downloading three XML files, each one with:

  • match results;
  • standings;
  • best scorers.

For the user interface I’ve used some standard iPhone controls (mainly for buttons) but the main screen is almost filled with an UIWebView.

What that means?

That means that the mainly part of our App UI is done using standard HTML web pages. I had some problems to implement this “workflow”, but after achieving that, it allowed us to easily tune our UI, using standard web technologies: HTML + CSS.

The main pages/views are obtained via XSLT:

XML -> XSLT (with CSS) applied -> HTML

So, when the App updates data, it receives three XML files, the correspondent XML data for the screen that the user is seeing, is transformed applying a corresponding XSLT file and then the new HTML page is generated and presented on the UIWebView.

I know this method is not so fast as if I had only used iPhone controls from the UIKit Framework for the views. But the pages scroll and transitions are fluid, except on the first time the App creates and presents each view, which take maybe 2 or 3 seconds do appear.

That’s not perfect, but it was a nice trade-off which allowed us to cut some time (that would be used to learn to use those controls) on our App development and design.

Nevertheless, in the future maybe it’ll be easily to port it to Android OS or any other platform which supports web views.

I’d like to hear your opinions and suggestions about this scheme or better alternatives. Leave me a comment…

Why the hell (Android) App Inventor is ONLY for amateurs / no developers!?

Update Note (March 14, 2012):

Google has discontinued App Inventor on December 31, 2011. Fortunately, it’ll now be maintained and evolved by MIT which has already relaunched it’s new beta version. You can check it at: “http://appinventoredu.mit.edu“.

In a near future, unlike Google’s version, I hope that MIT will let us export the source code of our apps created with App Inventor, and then continue it’s development on an IDE, like a usual Android app.


Original Article:

Today I decided to play a little bit with App Inventor for Android

I already knew that App Inventor has some limitations, for instance, currently it can’t be used to develop multiple screen apps. But that’s ok if your App doesn’t need to use those unavailable features.

I was thinking to try App Inventor and if I’d like it, maybe I could use it to create the base/core of some Apps. Then I’d export those Apps code to continue their development with Eclipse and Android SDK.
In this way I supposed that I’d be able to overcome those App Inventor restrictions, as far as I didn’t need to get my App back to App Inventor again.

So, after setting up my system (Mac + Android phone) I’ve started the first tutorial, Hello Purr. Below you see an App Inventor screen-shot with this tutorial App.

Figure 1: App Inventor - Hello Purr Tutorial

I was quite happy with App Inventor, specially with its Block Editor which is very interesting, specially because we can visually build Apps without writing on line of code! 🙂
It’ll certainly allow some non developers (and not only, I hope) to create their first Apps and it may motivate some of them to go further away and start learning how to program.

Figure 2: App Inventor - Block Editor

Kudos for Google folks by, as they say on the site, having reused the Open Blocks Java library (for creating visual blocks programming languages) distributed by the MIT’s Scheller Teacher Education Program which derives from thesis research by Ricarose Roque.

I’ll not describe blocks here but if you want to know more about it, take a look at the App Inventor Blocks Reference.

This is really great and I think that in a few years, much of the code programming (if we still can call it that, then) will be done with tools like Block Editor.

Now, let’s return to the topic of my post…
After happily hear the meoowww 🙂 of my tutorial cat on my phone, I was already thinking how it would be nice to use App Inventor to start porting our next iPhone App to Android.

But, then in the FAQs I realized that I can’t do it in the way I want, without being limited to the App Inventor features:

Can I develop in App Inventor and export the source code to Eclipse or some other IDE to work on it further?

No, App Inventor does not generate Java source code.”
(from: http://appinventor.googlelabs.com/learn/userfaq.html)

🙁

Well, I hope Google will reconsider it…
What do you think?

Do you think Google is right by not allowing the export of those App’s code, targeting App Inventor only to “amateurs” as I called it (with no pejorative intention) to designate non programmers which want to start creating their Apps?

Let me know what you think…

My first iPhone App on the App Store! :-)

I haven’t had time to write here, but soon I’ll try to start writing a lot of stuff I had learned with this little project.

By now, I only wan’t to let you know what was the project I had wrote a little about in my second post.

The final App name is South Africa 2010 Soccer Scores and you can find it on the App Store:

You can also see some info and screen-shots on our App @ http://xphone.me/sa2010ss/.

South Africa 2010 Soccer Scores - App Logo

South Africa 2010 Soccer Scores - App Logo

Unfortunately, I had this idea only some days before the World Cup started!

Nonetheless you developed it then we submitted it to the App Store. After 8 days we were notified of a possible copyright issue with a part of the original name of our App!

In less than a day we changed its name, the splash and title images, etc… and submitted it again…after one week it was approved and published on the App Store.

Unfortunately, that day was July 9th, less than 3 days to the end of the 2010 World Cup! :-/

Well, but in the last 3 days we had more downloads than we imagined from a lot of different countries!! That’s a little good return because it boosts our motivation to the next projects, especially an evolution of that App! 😉

And the work was worth it!! We got some experience and we learned a lot!!

Now we know what is to transform an Idea into a real App in the Apple App Store!

…and that is real a really nice feeling!! =:-)

Maybe on of this days I write a little post-morten about this App development.

I’d like to finish this post with kudos to André, he had done some really good logos/images for our App. And we had done a great team on this project. I’d also to thank to Eugen from Icon Drawer for letting us freely use his cute country flags

See you soon…

Ricardo

PS: If you try our App, please send us your comments & suggestions to “xphone.me@gmail.com“.

You have great ideas for mobile Apps? …but you don’t code?

You have great ideas for mobile Apps? You’d like to develop those ideas but don’t know how to program?

Now you can do it!!

Transform your ideas into real Apps for your Android phone, with Google App Inventor: http://appinventor.googlelabs.com.

I haven’t tried it yet but I think that for us, developers,it can be a very interesting tool because it allows us to sketch our Apps more faster. And it can be even better, if it allows us to take that sketch App code, and put it in the traditional pipeline, using Eclipse or other IDE to develop more advanced features.

Share your ideas with me, write a comment here…

© 2024 myDevNotes

Theme by Anders NorénUp ↑