Dear All,
Since Firefox OS will be HTML5 based, is this likely a failure? Take a look at Facebook failure when they create their android app using HTML5 and they decided will abandon this and goes native.
They just said HTML5 isn't fast yet although Android use Webkit (which faster than Gecko anyway).
I wonder how Firefox OS can handled complicated and bulky app like we already seen in playstore today.
Thanks
HTML5 can be faster
dels07 said:
Dear All,
Since Firefox OS will be HTML5 based, is this likely a failure? Take a look at Facebook failure when they create their android app using HTML5 and they decided will abandon this and goes native.
They just said HTML5 isn't fast yet although Android use Webkit (which faster than Gecko anyway).
I wonder how Firefox OS can handled complicated and bulky app like we already seen in playstore today.
Thanks
Click to expand...
Click to collapse
Regarding that, you should check out sencha's response to facebook. They built a HTML5 app, fastbook [ google it please, not allowed to post outside links .... yet ] that they say is faster and more feature rich than the native ones Facebook built after ditching HTML5.
HTML5 is not necessarily slower than native an especially since FirefoxOS will be doing away with the Dalvik Virtual Machine needed for android, it should have faster perfomance and fewer requirements.
The only way we can tell for sure is by running them and comparing so let FirefoxOS come out then do the comparison and pick whatever suits you
Faster than light
The point for FirefoxOS and Mozilla, it's that it implements WebApis that works with the Hardware of the devices that has installed FirefoxOS. All the WebApis are approved by the W3C, so don't worry about what it's better between native o web, the thing is how you develop your Apps, and how you implement the power of Gecko. Do you know how much frameworks and ways to make Web apps there are?
Related
Last night Google announced the Google Chrome open source OS.
This OS will be available for small ARM based devices up to full scale desktop/laptop x86 based devices. Google aims to create a nearly instant on OS with a high reliabilty and the ability to use the applications for Chrome in any (HTML5 Compatible?) browser on any other platform.
ANY WAY... ARM compatibility is nice
http://googleblog.blogspot.com/2009/07/introducing-google-chrome-os.html
Possible for it to run on the xperia?
dadeadman said:
Possible for it to run on the xperia?
Click to expand...
Click to collapse
Nobody knows. For now, it's just an initial announcement with no further details. We'll have to wait for them to release before we see, but it's basically just another window shell on top of a Linux kernel.
Which is fine with me. If google can release an OS that can be flexible enough for ARM to x86, and it WORKS, I'll be happy. I'd love to see a proper Linux ROM on our HTC devices.. it's a shame to be limited to a haret 'side boot' instead of a native ROM
l3it3r said:
Which is fine with me. If google can release an OS that can be flexible enough for ARM to x86, and it WORKS, I'll be happy. I'd love to see a proper Linux ROM on our HTC devices.. it's a shame to be limited to a haret 'side boot' instead of a native ROM
Click to expand...
Click to collapse
Considering WM devices have a REALLY bad habit of booting quite differently from maker to maker, I wouldn't be holding your breath for anything other than a haret based solution for quite some time...
Sense UI is slow on first-generation Android phones, and all the attempts to make it fast only result in a flaky, weird experience.
The framework and everything else is closed-source, what do you expect?
All we can do is extract the APKs and modify images and maybe tweak the AndroidManifest.xml or other xml files. Even if we can extract the bytecode (if that's what it's called for the DalvikVM), it still isn't as open as an AOSP build.
The only reason I flashed Rosie/Sense UI ROMs were to get a nice homescreen (which was slow) with nice widgets and a browser with Flash (that was slow and incompatible but still useful for simple stuff).
I would have fun with the ROM for a while, but when I needed to be productive, like Google something quickly or add a note in AK Notepad, it was painfully slow.
Android 2.2 Froyo is amazing. It has many features, the most important IMO being a reliable JIT compiler for the DalvikVM, and Flash 10.1 coming to the browser OFFICIALLY!
When the source for Android 2.2 is released and Cyanogen makes a release for the G1/Dream, I'm stuck on that until I get a super Android phone with a full QWERTY like the G1
Sense is also UGLY.
As for this flash thing... its not going to work on your phone. Compiled for a different CPU.
Nothing lost there though, flash is terrible trash that the world would be MUCH better off withOUT.
lbcoder said:
Sense is also UGLY.
As for this flash thing... its not going to work on your phone. Compiled for a different CPU.
Nothing lost there though, flash is terrible trash that the world would be MUCH better off withOUT.
Click to expand...
Click to collapse
Did Flash murder you in a previous life?
It seems 50% of your posts here are about how Flash is the end of civilization?
Flash is a dreadful battery/CPU hog, and I suspect the 'net, as Apple claim, would be better off without it.
That said, given the propensity of web designers to use nonstandard, bloated, un-necessary flash widgets that break navigation everywhere in their pages, making them utterly useless to those with old machines, accessibility needs/disabilities, etc I guess it's probably better to have it than not. Flash 10.1 under FroYo is only marginally quirky on my Desire. Getting there!
Sense, OTOH, I miss... LauncherPro just isn't as pretty. But I think on older hardware like the G1, I'd agree with the OP. It's not necessary to get the most out of Android and if it's causing slowdowns, it's a bit counter-intuitive to the actual purpose of a mobile phone.
Azurael said:
That said, given the propensity of web designers to use nonstandard, bloated, un-necessary flash widgets that break navigation everywhere in their pages, making them utterly useless to those with old machines, accessibility needs/disabilities, etc I guess it's probably better to have it than not. Flash 10.1 under FroYo is only marginally quirky on my Desire. Getting there!
Click to expand...
Click to collapse
How about just not visiting those websites? Most even halfway marginal websites will provide "if (no flash) then show these links instead", of the rest, you can certainly get the information somewhere else, or failing that, you probably don't want it anyway (the developer is obviously retarded...)
The big important thing to note is that the web is changing. There is MUCH MUCH MUCH less flash around than there was 10 years ago. In fact, I can't think of a single site that actually still *requires* it (except maybe a few sites hosting videos of retards doing stupid crap). I can think of a few that have flash ads -- in these cases, NOT having flash dramatically improves your experience.
Different architectures
I remember a while back that there was a bug in Sense on the Hero where the package name (com.google.maps) would be displayed instead of the actual application name (Maps).
HTC acknowledged the problem and fixed it, but that's the problem with Sense; if it were open-source, someone (probably on xda) would release a tiny patch to fix the problem. Like if Google made the same mistake in the default Launcher, it would be fixed by the devs online quickly.
And now about Flash: What!? Wasn't it built for ARM? Or do the N1 and other superphones use a slightly different architecture? This is weird...
Another problem is that there are netbooks and all sorts of smartphones with Android.
Most netbooks will have x86 processors (Intel, AMD) and though most smartphones are expected to use ARM, some might use a different architecture like MIPS, or even x86 in the future.
Normal Android applications that are made with Java are fine, but how about all the apps with native binaries built with the Android NDK?
What Google should do is implement a way to compile the same program to all popular architectures, and keep the different binaries in the APK.
Apple did something similar in Mac OS X when they switched from PowerPC to Intel... application files in Mac OS X are basically a package that holds basic information, icons, and the binaries, which make this file format similar to Android APKs, except that when someone compiles their program for OS X, both PowerPC and Intel binaries are compiled and stored in the application.
If Google does this for Android, there will be no problem with different architectures (like with Flash not being able to run on the G1)
PSP_Hacker said:
I remember a while back that there was a bug in Sense on the Hero where the package name (com.google.maps) would be displayed instead of the actual application name (Maps).
HTC acknowledged the problem and fixed it, but that's the problem with Sense; if it were open-source, someone (probably on xda) would release a tiny patch to fix the problem. Like if Google made the same mistake in the default Launcher, it would be fixed by the devs online quickly.
And now about Flash: What!? Wasn't it built for ARM? Or do the N1 and other superphones use a slightly different architecture? This is weird...
Click to expand...
Click to collapse
Just like i686 binaries won't run on an i486 CPU, ARM7 binaries won't run on an ARM5 CPU. There are architectural changes that break compatibility of new binaries on old hardware.
Another problem is that there are netbooks and all sorts of smartphones with Android.
Most netbooks will have x86 processors (Intel, AMD) and though most smartphones are expected to use ARM, some might use a different architecture like MIPS, or even x86 in the future.
Normal Android applications that are made with Java are fine, but how about all the apps with native binaries built with the Android NDK?
Click to expand...
Click to collapse
Not all native applications are built with the NDK. Flash is a big example -- it has a lot of HAND WRITTEN ASSEMBLY CODE. There is NO automatic way to generate hand written assembly code. Each additional platform you support MUST have its own manually written code.
What Google should do is implement a way to compile the same program to all popular architectures, and keep the different binaries in the APK.
Click to expand...
Click to collapse
http://developer.android.com/sdk/ndk/index.html
Might not be a bad idea to read up on the ndk.
The applicable line is "You can also build for both architectures at the same time and have everything stored in the final .apk". Seems that they already thought of this
*** but it isn't applicable to flash since flash is partially hand-written. They could easily include the various binaries within a single APK file, but that won't happen unless they actually build the arm5 binary, which is extremely unlikely.
If Google does this for Android, there will be no problem with different architectures (like with Flash not being able to run on the G1)
Click to expand...
Click to collapse
For reasons mentioned above, this doesn't help.
Can somebody port (or try to) the flash player to the armv6 processor?
It sucks be without flash... =(
cannot agree more!
If its possible on over clocked processors then please do that
Like if I have 1ghz above out will be enough for flash and phone too will be smooth enough
Not possible at all, the same thing goes on with Flash on iPhone 2G, 3G, iPod touch 1G and 2G. All those devices have ARM6 CPU's and it just isn't possible to backport it like that. If it was, it would have happened years ago.
GazaIan said:
Not possible at all, the same thing goes on with Flash on iPhone 2G, 3G, iPod touch 1G and 2G. All those devices have ARM6 CPU's and it just isn't possible to backport it like that. If it was, it would have happened years ago.
Click to expand...
Click to collapse
but I've heard that iphone has some similar app for flash... something like "frash" maybe
brunoshady said:
but I've heard that iphone has some similar app for flash... something like "frash" maybe
Click to expand...
Click to collapse
Frash also uses libflashplayer.so from the android build which is based on ARMv7 or later.
@everyone:
However, IT IS POSSIBLE to port Flash to ARMv6. However, it would be a lot of work and it will be really buggy and slow. A better alternative would be to encourage the development of GNASH which already works on ARM but doesn't have a browser plugin yet.
GNASH is also buggy but we do have the source. As for Flash, it has to be reverse engineered. Plus, Adobe itself is convinced that Flash is going to die in lieu of HTML5 and so they have started experimenting Flash to HTML5 conversion tools. Such a tool has already been released but sadly it works only with simple banners and not with games and such.
nibras_reeza said:
Frash also uses libflashplayer.so from the android build which is based on ARMv7 or later.
@everyone:
However, IT IS POSSIBLE to port Flash to ARMv6. However, it would be a lot of work and it will be really buggy and slow. A better alternative would be to encourage the development of GNASH which already works on ARM but doesn't have a browser plugin yet.
GNASH is also buggy but we do have the source. As for Flash, it has to be reverse engineered. Plus, Adobe itself is convinced that Flash is going to die in lieu of HTML5 and so they have started experimenting Flash to HTML5 conversion tools. Such a tool has already been released but sadly it works only with simple banners and not with games and such.
Click to expand...
Click to collapse
what is GNASH?
brunoshady said:
what is GNASH?
Click to expand...
Click to collapse
Open source Flash player.
http://www.gnu.org/s/gnash/
Check this out
http://forum.xda-developers.com/showthread.php?t=1155538
Hi everyone,
UC Browser Mini is based on our classic U2 kernel. With fast and smooth browsing on Android mobile devices, UC Browser Mini is a great tool for watching online videos. If you want a lightweight browser and fast browsing experience, UC Browser Mini is the best mobile browser for you.
New Features:
1. Increased Speed
Both start up and downloading speed has been greatly increased.
2. Even Lighter
Functions have been trimmed so the browser takes up even less storage space.
3. More Languages Supported
You can now browse in Russian, Spanish and Portuguese.
4. Improved Stability
The browser has been optimized to give you an even smoother browsing experience.
UC_Browser said:
Hi everyone,
UC Browser Mini is based on our classic U2 kernel. With fast and smooth browsing on Android mobile devices, UC Browser Mini is a great tool for watching online videos. If you want a lightweight browser and fast browsing experience, UC Browser Mini is the best mobile browser for you.
New Features:
1. Increased Speed
Both start up and downloading speed has been greatly increased.
2. Even Lighter
Functions have been trimmed so the browser takes up even less storage space.
3. More Languages Supported
You can now browse in Russian, Spanish and Portuguese.
4. Improved Stability
The browser has been optimized to give you an even smoother browsing experience.
Click to expand...
Click to collapse
what does this offer compared to the normal version, also there is a tablet version, what are the differences
maverickronny said:
what does this offer compared to the normal version, also there is a tablet version, what are the differences
Click to expand...
Click to collapse
There are several facts that forces users to use mini version rather than normal version. Its becz of the below features :
1. Extremely low size
2. Consumes less memory
3. Provide super fast speed
Some bulky features implemented in normal version is not present here. Android mini version gives users full satisfaction in using it.
Tablet version is meant for only tablet devices. But Android Normal and mini version intended for Android platforms.
UC_Browser said:
UC Browser Mini is based on our classic U2 kernel.
Click to expand...
Click to collapse
How can a browser be based on a kernel
shobon said:
How can a browser be based on a kernel
Click to expand...
Click to collapse
Its based on abstraction features. Inheriting the most essential features without including the background details. I aM not well expert in android & only a beginner. Our program developer are expert in this.
UC_Browser said:
Its based on abstraction features. Inheriting the most essential features without including the background details. I aM not well expert in android & only a beginner. Our program developer are expert in this.
Click to expand...
Click to collapse
I always hated UC browser for the GB look. #holoyolo
Does it support flash
Sent from my GT-I9505G using xda app-developers app
Turkish support
Turkish language support you can add?
There's also a UC browser mini in play store!
Is this the same or different?
text reflow supported/????
one if the greatly missed features google killed.
Play store version of UC browser mini is 8.9.2 and this one is 8.7!
Old version huh?
Ichigo said:
So, as you all know Android kitkat 4.4 came out recently. Along with it was ART, a replacement for Dalvik that promises faster and more efficient execution, better battery life, and a more fluid experience. ART stands for Android Runtime, and executes apps different than Dalvik. ART uses AOT to execute apps, which is pre-compiling bytecode into machine language when apps are first installed, turning them into truly native apps. ART still is still experimental currently, but let's discuss our opinions.
I know that when programming games for android, if it uses heavy 3D translations, you'll to use the NDK, coding in C or C++, allowing the app to run natively, and helps maintain frame rate and speed. Because the ART has apps running natively now, will it possibly help maintain framerate and speed better on lower-end devices? I know java is much slower slower than c++, but will running the java coded app natively help at all?
Anyways, share your opinions, ideas, or questions.
Click to expand...
Click to collapse
I don't know much about ART, but from what I heard this sounds awesome . I think that it is just crazy not to precompile the code into machine language, sure there is longer install times, but hey, the apps should run much faster.
The thing is that currently it is quite hard to try it out, even on KitKat (which I don't have yet). Would love to make a comparison between the two
Here are some benchmarks by Android Police: http://www.androidpolice.com/2013/1...ormance-wont-blow-away-today-will-get-better/
I hope that they will improve that method. If they do, it will be amazing.
Apps could much faster.
I do, however, like Java. One of the reasons why I prefer Android to Ubuntu Touch (which uses C++).
nikwen said:
Here are some benchmarks by Android Police: http://www.androidpolice.com/2013/1...ormance-wont-blow-away-today-will-get-better/
I hope that they will improve that method. If they do, it will be amazing.
Apps could much faster.
I do, however, like Java. One of the reasons why I prefer Android to Ubuntu Touch (which uses C++).
Click to expand...
Click to collapse
When KitKat comes to Nexus 4 I'll do some before/after benchmarking on MagicKeyboard (since it is fairly predictable and CPU intensive) - sounds quite promising.
PicomatStudios said:
When KitKat comes to Nexus 4 I'll do some before/after benchmarking on MagicKeyboard (since it is fairly predictable and CPU intensive) - sounds quite promising.
Click to expand...
Click to collapse
Kitkat is here on our Nexus 4s.
nikwen said:
Kitkat is here on our Nexus 4s.
Click to expand...
Click to collapse
Aw, yeah... I try to make a rule that wherever possible I use 'standard' build on our test devices, that way I can be sure I'm seeing what our users see
Depending how long it takes I might have a look !
PicomatStudios said:
Aw, yeah... I try to make a rule that wherever possible I use 'standard' build on our test devices, that way I can be sure I'm seeing what our users see
Depending how long it takes I might have a look !
Click to expand...
Click to collapse
Now the official ones are finally here.
nikwen said:
Now the official ones are finally here.
Click to expand...
Click to collapse
OK got it finally.
In a not particularly scientific test I tried typing the sentence
'The quick brown fox jumped over the lazy dog.'
into Magic Keyboard 2 (as many other apps as possible stopped, internet off, etc)
After each key press the app runs quite a large number of comparisons/calculations/bitshifts in a loop, in order to score the most likely word (CPU intensive work)
I only ran the test 3 times but there does seem to be an improvement with ART
Average prediction time for each configuration is:
Android 4.3:
20ms
Android 4.4 / Davlik:
19ms
Android 4.4 / ART:
15ms
From previous tests I know that the prediction times are fairly consistent.
Obviously the above is some way short of proof but early signs are good.
i am on android 4.4.4 with art runtime i haven't noticed any performance enactment and also not a single app cashing
Sent from my XT1022 using XDA Free mobile app