Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (6)
to General by Kalatti - 6 days, 5 hrs ago - more...
| The Following User Says Thank You to danramos For This Useful Post: | ||
 |
|
2011-06-18
, 04:09
|
|
Posts: 1,789 |
Thanked: 1,699 times |
Joined on Mar 2010
|
#3742
|
I figured out the problem with Android tablets (mostly lack of honeycomb apps) and the fault is entirely Google's.
Google put Android development into overdrive when they gave away/sold/released the Nexus One in Jan '10 ...with an 800 x 480 resolution screen.
It would've been wise to set the resolution at 800 x 450. Then its 16:9 format and still a relatively similar pixel count/density. But...
Then tablets should be released with a 1600 x 900 resolution. So that smartphone applications could be zoomed in (x4) like the iPad. It could also place 3 rows of smartphone applications (800x450) in landscape mode and leave 100 pixels on the bottom ... say for the android buttons/notification bar. Then "Honeycombe OS" should also have its own native apps built with 1600x800 (to leave 100px for the notif bar) and the new 16:8 (or 2:1) ratio would make it simple to go from landscape to portrait mode.
Then in 2011/2012 should be the era of High Definition smartphones, so basically qHD resolution (960x540). [which would bump the ppi from 204 to 245 for a 4.5" phone]
Later we could see FullHD tablets! 1920x1080p!!!
It would zoom (x4) the qHD smartphone apps to cover the fullscreen. Then also it could place 3 rows of qHD smartphone apps in landscape mode leaving 120 pixels for the notifications bar. The new SDK should allow tablet apps to be built in 1920x1080 (or 1920x960 for 2:1 ratio), which means it gets close to the grunt/quality of an Xbox 360.
So yeah, 30 pixels too-greedy is what prevented this awesomeness from happening, 'tis a shame!
(anyone agree/disagree?)
Last edited by Kangal; 2011-06-18 at 04:32.
Google put Android development into overdrive when they gave away/sold/released the Nexus One in Jan '10 ...with an 800 x 480 resolution screen.
It would've been wise to set the resolution at 800 x 450. Then its 16:9 format and still a relatively similar pixel count/density. But...
Then tablets should be released with a 1600 x 900 resolution. So that smartphone applications could be zoomed in (x4) like the iPad. It could also place 3 rows of smartphone applications (800x450) in landscape mode and leave 100 pixels on the bottom ... say for the android buttons/notification bar. Then "Honeycombe OS" should also have its own native apps built with 1600x800 (to leave 100px for the notif bar) and the new 16:8 (or 2:1) ratio would make it simple to go from landscape to portrait mode.
Then in 2011/2012 should be the era of High Definition smartphones, so basically qHD resolution (960x540). [which would bump the ppi from 204 to 245 for a 4.5" phone]
Later we could see FullHD tablets! 1920x1080p!!!
It would zoom (x4) the qHD smartphone apps to cover the fullscreen. Then also it could place 3 rows of qHD smartphone apps in landscape mode leaving 120 pixels for the notifications bar. The new SDK should allow tablet apps to be built in 1920x1080 (or 1920x960 for 2:1 ratio), which means it gets close to the grunt/quality of an Xbox 360.
So yeah, 30 pixels too-greedy is what prevented this awesomeness from happening, 'tis a shame!
(anyone agree/disagree?)
Last edited by Kangal; 2011-06-18 at 04:32.
| The Following 3 Users Say Thank You to Kangal For This Useful Post: | ||
 |
|
2011-06-18
, 16:30
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#3743
|
Originally Posted by danramos
I think fragments do this very well, its just that the *way* that certain aspects of the system (as it relates to UI) are implemented that shows lack of a unified vision.
...or... simply make it easy to write apps that adjust well to differing resolution and orientations (ala properly written HTML5, for example).
For example.
Android has a tertiary language called Renderscript to produce very quick graphic code. Now, this is cool and all, but requires programmers seeking performance not only leverage Java to produce their works, but also C (C99 to be precise), compile to a renderscript file (LLVM bitcode), and then tie-in to their java application. Wha???
It seems clear that renderscript is the brainchild of a small group that sees its benefits, but that the Dalvik VM is the brainchild of another group and they are being duct-taped to one another. Now I'm not saying that interoperability is bad; it's quite good. I am saying that why on earth should you need to write your program in possibly three languages (Java, JNI Native, and Renderscript) to produce well running code? This is the type of complexity that can be avoided.
Renderscript is a very cool concept, but why, if you're compiling LLVM would you call it Renderscript, confine it to C, and limit its main functionality to UI graphics? Why not compile Java to LLVM bitcode, and work on perfecting a better LLVM compiler rather than Dalvik? It shouldn't be Renderscript, it should be Generalscript, and the language language should be arbitrary -- that's the point of LLVM!
My point is this: If Renderscript is so fast, and can be called and call Java in the Dalvik VM, offer it as an alternate to Java and not a specialist tool.
It makes little sense.
Additionally, fragments are cool, and views are cool, but put some sparkles on it for goat sake! There should be pre-baked APIs for doing cool animations and transitions and otherwise making the UI look pretty whilst being pieced together in XML. There should be layouts that are proven to work with different form factors easily selectable for developers so all they have to do is go to a page, see a layout that looks cool and would work with their site, watch a video of it in action, download it, and fill in the code behind the interface, and reap the benefits of cross-platform UI goodness.
Lets face it: tablet UIs are all pretty darn simlar, why not take the work out of it, and make it easier for developers? In my perfect world, developers would be able to select portions of the UI from examples, piece them together, and fill in the logic.
Currently, this is not how things are done. Its not terribly hard now, but it's different enough to make it a learning experience to jump in, which may turn some folk off, or increase the amount of time it takes to deploy an app.
| The Following User Says Thank You to Capt'n Corrupt For This Useful Post: | ||
|
|
2011-06-18
, 17:45
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#3744
|
Originally Posted by Kangal
I would have to heartily disagree.
I figured out the problem with Android tablets (mostly lack of honeycomb apps) and the fault is entirely Google's.
Google put Android development into overdrive when they gave away/sold/released the Nexus One in Jan '10 ...with an 800 x 480 resolution screen.
Fragments give Android a distinct advantage over UIs that assume a solitary size especially considering the plethora of devices that Android targets.
Remember it's not just about the resolution, but the PPI that determines the size of on-screen objects. Sure on your 10" tablet a 24x24 pixel icon would be selectable, but it would be far too small 3.5" phone .
The Apple solution of 'pixel doubling' doesn't work very well for non-single sku items. For example:
- Suppose you write a tablet app but want the app on a phone? You're forced to port the application and re-think the UI
- Suppose you chose to port your app to a different screen (eg. TV)? You're forced to port the application and re-think the UI
- Suppose your apps will be more than one per screen in a windowed arrangement? You're forced to port the application and re-think the UI
- Suppose you wish to support a new screen resolution (even with the same aspect ratio)? You're forced to port the application and re-think the UI
Pixel doubling doesn't cut it unelss you only have one or two products.
The Android solution is *far* superior for its application: supporting multiple devices, some of which are currently not known. In fact, the entire OS is built around this, and is readily seen with Java being the choice language and fragments (for example).
I just personally think that these facilities could be made more easily available to the developer.
|
|
2011-06-18
, 17:49
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#3745
|
http://androidandme.com/2011/06/phon...t-uplinq-2011/
VIDEO: http://www.youtube.com/watch?v=cxqdY81L0yw
Here is HTC's CEO Peter Chou talking about the future of mobile.
Not terribly informative, but interesting enough, I suppose.
| The Following User Says Thank You to Capt'n Corrupt For This Useful Post: | ||
|
|
2011-06-18
, 20:49
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#3746
|
Droiddog givew the Sensation a sensational review:
http://www.droiddog.com/android-blog...ion-4g-review/
They really like Sense UI!
Having never used Sense cannot say weather or not I like it, but I like that HTC is providing a very differentiated experience, despite still being Android.
The trick is to modularize the UI enough such that it is still possible to push updates quickly without a huge lag time between official releases.
I also like that HTC uses Qualcomm a true ARM competitor.
http://www.droiddog.com/android-blog...ion-4g-review/
They really like Sense UI!
Having never used Sense cannot say weather or not I like it, but I like that HTC is providing a very differentiated experience, despite still being Android.
The trick is to modularize the UI enough such that it is still possible to push updates quickly without a huge lag time between official releases.
I also like that HTC uses Qualcomm a true ARM competitor.
| The Following User Says Thank You to Capt'n Corrupt For This Useful Post: | ||
|
|
2011-06-18
, 21:02
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#3747
|
John Carmack (the man who gets way more credit than he deserves 
) has shared a little insight into the future of console games.
Carmack: Next consoles in 2013, 10x the power
http://www.geek.com/articles/games/c...ower-20110616/
It seems that while mobiles catch up to current consoles in the next year, they will be severely out-gunned by the consoles in the future! Tegra 4 may be hot next year, but will it be enough to contend with graphics of future devices? Similarly are graphics enough to pry gamers from mobile games that are commanding ever larger market shares?
Time will tell....
) has shared a little insight into the future of console games.Carmack: Next consoles in 2013, 10x the power
http://www.geek.com/articles/games/c...ower-20110616/
It seems that while mobiles catch up to current consoles in the next year, they will be severely out-gunned by the consoles in the future! Tegra 4 may be hot next year, but will it be enough to contend with graphics of future devices? Similarly are graphics enough to pry gamers from mobile games that are commanding ever larger market shares?
Time will tell....
| The Following User Says Thank You to Capt'n Corrupt For This Useful Post: | ||
|
|
2011-06-18
, 22:24
|
|
Posts: 1,179 |
Thanked: 770 times |
Joined on Nov 2009
|
#3748
|
Want to format my Tab. Battery is a mess, market app shuts down when I open and even when it works have so many errors when trying to update apps. Device also very often unstable.
What is the best way to back up before formatting. Is there an app (free) which can backup all your apps, data and settings? Preferably to PC since micro sd card can't fit it unless the back up has some incredible compressing.
What is the best way to back up before formatting. Is there an app (free) which can backup all your apps, data and settings? Preferably to PC since micro sd card can't fit it unless the back up has some incredible compressing.
| The Following User Says Thank You to etuoyo For This Useful Post: | ||
 |
|
2011-06-18
, 23:12
|
|
Posts: 4,672 |
Thanked: 5,455 times |
Joined on Jul 2008
@ Springfield, MA, USA
|
#3749
|
Originally Posted by etuoyo
The only really reliable ways to back-up the Tab are either 1) Titanium Backup (and you CAN use dropbox, if you don't want to store onto the SD card... but if I'm not mistaken, it still needs space on the SD card to store it even if it's temporarily). or 2) ClockworkMod (after converting to ext4 from rfs)--but definitely needs the SD card.
Want to format my Tab. Battery is a mess, market app shuts down when I open and even when it works have so many errors when trying to update apps. Device also very often unstable.
What is the best way to back up before formatting. Is there an app (free) which can backup all your apps, data and settings? Preferably to PC since micro sd card can't fit it unless the back up has some incredible compressing.
Alternatively, mind you I've never done this though, I think you might be able to use adb to create dd images on the SD card, then transfer them to your PC.
__________________
Nokia's slogan shouldn't be the pedo-palmgrabbing image with the slogan, "Connecting People"... It should be one hand open pleadingly with another hand giving the middle finger and the more apt slogan, "Potential Unrealized." --DR
Nokia's slogan shouldn't be the pedo-palmgrabbing image with the slogan, "Connecting People"... It should be one hand open pleadingly with another hand giving the middle finger and the more apt slogan, "Potential Unrealized." --DR
| The Following 2 Users Say Thank You to danramos For This Useful Post: | ||
|
|
2011-06-18
, 23:38
|
|
Posts: 1,789 |
Thanked: 1,699 times |
Joined on Mar 2010
|
#3750
|
Originally Posted by Capt'n Corrupt
No you misunderstood. If you have used android applications on devices with different screen resolutions (eg 800x600) you soon come into contact with many problems (I can vouch for this because I purchased the Herotab for $150 on ebay). The elements become stretched and shrunk and some are shifted out of the screen, and some applications refuse to start. Hell, you can notice some of this on the MotoDroid because of 3.7" 854x480.
I would have to heartily disagree.
Fragments give Android a distinct advantage over UIs that assume a solitary size especially considering the plethora of devices that Android targets.
Remember it's not just about the resolution, but the PPI that determines the size of on-screen objects. Sure on your 10" tablet a 24x24 pixel icon would be selectable, but it would be far too small 3.5" phone .
The Apple solution of 'pixel doubling' doesn't work very well for non-single sku items. For example:
- Suppose you write a tablet app but want the app on a phone? You're forced to port the application and re-think the UI
- Suppose you chose to port your app to a different screen (eg. TV)? You're forced to port the application and re-think the UI
- Suppose your apps will be more than one per screen in a windowed arrangement? You're forced to port the application and re-think the UI
- Suppose you wish to support a new screen resolution (even with the same aspect ratio)? You're forced to port the application and re-think the UI
Pixel doubling doesn't cut it unelss you only have one or two products.
The Android solution is *far* superior for its application: supporting multiple devices, some of which are currently not known. In fact, the entire OS is built around this, and is readily seen with Java being the choice language and fragments (for example).
I just personally think that these facilities could be made more easily available to the developer.
What I'm trying to say is that Google should've pushed hard with making apps fragmenting the user elements for the specific pixel density and screen size ... but Google could've used a little foresight and choose the 800x450 or 800x400 resolution on the Nexus One. Yes losing 30-80 pixels isn't a great thing but the screen density really doesn't suffer too much and it makes it a real treat to use the tablet when it allows the user to use it in such great form.
And this strategy would push developers to make applications for the smartphone, then also give them time, to port their application to the tablet's native resolution (1600x900 or 1920x1080).
Think about it, as a developer you have your ideas for your application, and if you follow a simple resolution "rule of thumb" 800x450->1600x900 or qHD->FullHD, it makes it that much easier to reach out to more devices (as you require less testing) and potentially the time you saved can be used to make the app more polished (which is what I'm constantly hearing from iOS developers that made the switch to android).
Here:
800x400 on 4.5" is 199PPI
800x450 on 4.5" is 204PPI
800x480 on 4.5" is 207PPI
854x480 on 4.5" is 218PPI
960x540 on 4.5" is 245PPI
(it only costs 3-8PPI which isn't that much, do note that opthamologists say any amount above 220ppi cannot be detected by the human eye at 20cm from face unless stared at for over 60seconds on non-moving objects which really never happens, but the quality of screen used can definitely be picked up with the first glance sometimes even with moving objects)
edit: I failed to explain myself again.
I'm saying android is pretty good the way it is right now, but its not perfect and this is because developers are lazy. If Google chose the same path but pressured other OEMs to stick with 800x400 or 800x450 then most (lazy) developers would make their app suited for 800x400/450 and this would scale perfectly for tablets. If developers weren't this lazy there would be no need for this but that isn't the world we live in, which is why such a strategy would've been awesome is all im trying to say.
Last edited by Kangal; 2011-06-19 at 13:19.
| The Following 2 Users Say Thank You to Kangal For This Useful Post: | ||
 |
| Tags |
| android envy, buzz..buzz buzz, core failure, crapdroid, galaxy fap, galaxy tab, ipad killer, samsung, tab trolls, tablet envy |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 08:55.
Nokia's slogan shouldn't be the pedo-palmgrabbing image with the slogan, "Connecting People"... It should be one hand open pleadingly with another hand giving the middle finger and the more apt slogan, "Potential Unrealized." --DR