Remember, all I’m offering is the truth – nothing more – week 5
Week 5 was about the different types of mobile applications: online, hybrid, native, meta. It`s a topic I thought would be covered by one of the previous weeks as it counts more into the basic understanding section.
All three main types were discussed with pro and cons, and it is pretty clear now to me that SAP is pushing mobile developers to code native apps. Even the benefits of a mobile web page were presented with some snobism; as if mobile developers that are not coding native apps do not really count. While one of the benefits of native development is full access to device features, when do you need this in the context of a business application? You know, the logon -> list -> detail -> dialog style apps. That can be done with a hybrid or mobile app too, and going HTML5 saves you a lot of trouble. Specially when the non mobile users want the same new UI. In case you want to do a approval app inspired by Angry Birds: go ahead and develop it as a native app (“you travel was rejected as your manager only scored 1 star”).
To give you an example, some mobile web dissing was practiced in unit 2 when a mobile logon page with SAPUI5 was shown. The “big problem” pointed out was that it takes a lot of requests to load the resources needed to access the logon page: 82 requests.
Well SAP, only you. And only with SAPUI5. Let’s take a look at a real world mobile logon, like from LinkedIn.
That’s 10 requests for loading the logon page https://touch.www.linkedin.com/login.html for the first time. And if you just enter m.linkedin.com you get some redirects, but with cache enabled, it just 8 requests.
8 vs. 82. That mobile online web app deficit should be revised when the course is offered once more.
When the topic came to meta apps I was silently hoping that Syclo will be part of this week. Maybe even a trial of Syclo in SMP for course participants? Well, unfortunately, this wasn`t the case. At first I thought this week will be theory only. I was wrong. Some coding happened and in the download section 3 apps appeared, 1 HWC and 2 native Android apps. Luckily, these worked with the Gateway demo system provided. No coding inside Gateway needed this time!
The HWC sample app imported fine, but showed an error. A JAR file could not be found. This was a left over from the original source.
After deleting this reference the WHC app started and worked just fine. The 1st Android app started fine after the changes in the property file were done. The application connections in my SMP trial account are filling up:
I wasn`t able to start the 2nd Android application with the GMC feature; and honestly I am also too lazy to investigate the problem further.
Remains only one question: web, hybrid, native, meta? There is no answer, it depends on your scenario. This also means: when your scenario changes, you may have to switch. Plan accordingly.
Other blogs in this series from me about the open SAP course: Introduction to Mobile Solution Development
- Survived week 1: Introduction to Mobile Solution Development
- Still alive after week 2: Enterprise Mobility Enablement Services
- Any given Tuesday – week 3: Introduction to Mobile Solution Development
- Do apps dream of electric sheep? Week 4
- Remember, all I’m offering is the truth – nothing more – week 5
- Open the pod bay doors, SMP – week 6
Hello Tobias,
I think this is unfair to compare the toolkit with the social network, which had been optimized to work with millions of users.
Did you see which code is generated by the server for the login.html page? Lots of human-unreadable lines of code. Yes, of course the optimized page (with compressed scripts, bundled resources, enabled caching... I am not talking about precompiled for well-known social network) always wins against a construction tool.
Non-optimized jQuery is also slow. That is why tools like jQuery UI Builder exist. If you know the future page design, you can combine required libraries only into a single file. The same can be applied to CSS files and even images (if you know what I mean).
The code optimization is the thing which cannot be done automatically at 100%. You should always think how your code will be supported, and how good you can optimize it.
The toolkit is always the toolkit. You cannot have the rich grid with many themes and write 1-2 lines of JavaScript code to have a super light HTTP request.
Kind regards,
Vlad
Hi Tobias,
I got a different impression here ( I have already worked on a native iOS app with SUP couple of years years ago and have been late to the JS party, learning AngularJS now).
- The example app hasn't been a native app but uses JS. I think it's fair to say that some features are still not complete especially if you start scaling the app and Craig was just highlighting that fact.
- The course is meant as an "introduction" offering mobile development with SAP's platform and hence covering certain optimizations may not be the focus.
I've enjoyed the course and happy with the format.
Cheers
Vikas
Hi Tobias,
As far as I know the number of downloads doesn't really matter anymore. HTML Keep-Alive should, the default from HTTP 1.1 should make sure that this doesn't lead to multple connections being opened and closed all the time.
I find the footprint more reason for worry though. In a recent POC I did, I counted 3MB going over the line before the first screen showed. Those are Webdynproesque proportions if you tell me.
Even though there are good CDN options (akamai etc), it would be good to push SAP to see if the footprint can be slimmed down.
Cheers,
Jan
Jan,
of course it does matter. There is more to a request than opening a TCP connection. Files get requested, and there is a difference if you request 4 files or 80. Even when you cache them, it still 80 files the browser has to handle, and when requested, there is the HTTP protocol overhead.
AFAIK SAP is working on a tool to optimize SAPUI5 in that regard, but until it is released it is hard to know if it works.
Btw, that is one of the cases where open source SAPUI5 makes sense. For sure someone would already have released such a tool.
Of course it matters, but opening local files (either on the server, or in browser cache), hardly makes any difference as compared to opening a remote TCP connection 80 times.
I think spdy would be very beneficial in a UI5 environment btw, in which multiple connections are opened at the same time. Actually UI5 is ideal for it, because of the multitude of tiles being download. I should experiment with that sometime.
Not sure if sure if spdy is available on mobile devices though, so I´m not sure if it would help in your case...
Hi Tobias,
unfortunately I only noticed this blog post now, 6 weeks after it has been written (thanks to a different blog by John Moy).
When I read:
"some mobile web dissing was practiced in unit 2 when a mobile logon page with SAPUI5 was shown. The “big problem” pointed out was that it takes a lot of requests to load the resources needed to access the logon page: 82 requests"
I was surprised to say the least.
The screenshot listing files liek "InputBaseRenderer.js" and "ButtonRenderer.js" is clearly taken from a non-optimized application where two files are loaded per control, which is of course not acceptable for productive use.
I have to admit SAPUI5 documentation about performance optimization is not perfect, so this could happen to outside developers. We are working on this.
BUT when something coming from SAP uses unoptimized apps to "prove" that HTML (specifically UI5) is inferior to native apps, I'd expect a little better investigation before making such claims public.
UI5 apps running in non-dev mode load ALL JS of a control library in one file ("library-preload.js"), which contains the single JS files not only concatenated but also stored as strings, so the JS parser only runs for the pieces which are actually required.
This results in only 11 request for a typical, simple SAPUI5 application.
Don't take my word for it, but try it here:
http://jsbin.com/aku-mobile-list-databinding
(There are 18 requests in total, but 7 are caused by jsbin and Google Analytics applied by jsbin)
No doubt: the loaded 1.8 MB are too much and we are working on this as well. (also working on reducing the 11 requests further, in particular because loading more libraries or application resources will increase the number of requests from 11).
But a claim that SAPUI5 needs 87 requests for a a login screen is just wrong.
I'll investigate where exactly this comes from and offer my support to find out the actual facts.
Regards
Andreas