36 replies to this topic

[Hell-In-A-Handbasket]

techbeck, on 04 May 2012 - 19:21, said:

Kinda doubt that. They will lose out on a lot of money if they limit the phones. No reason to limit it really.

They could be doing how they did it when it first came out, was invite only, had to sign up on a list so they could upgrade their back end as they went, not mad house all at once.

They could be doing the Gal first, upgrading capacity as needed, then same with other phones, then with the rest.

[HawkMan]

That's not what select handsets mean.

[Hell-In-A-Handbasket]

HawkMan, on 04 May 2012 - 19:41, said:

That's not what select handsets mean.

Don't know if that's a reply to me or somebody else.

If me, it could be like it was originally, select limited release so they could upgrade backed as needed

[Boz]

HawkMan, on 04 May 2012 - 19:10, said:

Available on select android handsets.... What was that thing android wasn't again...

Maybe if you understood what's happening in the development process you would realize why they are doing it this way.

Flipboard is a very specific type of app that tied their UI to the single resolution with the animations and layout. It is a bit harder to target the same type of UI on various devices and different resolutions due to the way they designed it, not because Android is fragmented.

The bottom line is how you designed the app. The reason they are launching with Galaxy S3 is publicity but I can guarantee you that the same app will work on Galaxy Nexus due to the screen resolution. They are most likely trying to port their existing UI and it's not as flexible to work with different resolution and scale properly.

They wouldn't have had this problem if they designed the app from the ground up for Android first.

When you design for Android, and follow the guidelines and not work with absolute layouts in your UI the app will work on all devices just fine. That's why Android deals with views and units in DPs (density independent pixels) and SPs instead of standard pixels and has attributes on objects like weight and deals with linear, relative and other types of layouts.

[HawkMan]

Boz, on 04 May 2012 - 19:54, said:

Maybe if you understood what's happening in the development process you would realize why they are doing it this way.

Flipboard is a very specific type of app that tied their UI to the single resolution with the animations and layout. It is a bit harder to target the same type of UI on various devices and different resolutions due to the way they designed it, not because Android is fragmented.
.

You just said, they do it because fragmentation makes it harder to develop the app, but android isn't fragmented. you have to decide.

[HawkMan]

Boz, on 04 May 2012 - 19:54, said:

They wouldn't have had this problem if they designed the app from the ground up for Android first.

Umm, yes they would.

[Boz]

HawkMan, on 04 May 2012 - 20:03, said:

Umm, yes they would.

Based on what? I am building Android apps. I never had a problem with any of the apps to run on various Android devices. The only limitation is where you target a minimum SDK which today is really Android 2.x. And there are things like Android Compability Libraries that work ICS 4.0 APIs (http://developer.and...ty-library.html) that allows you to use ICS features and code that works fine on older versions of Android too (it even goes down to Android 1.6).

Tell me specifically why they would have problems? Give me examples. Because from my perspective as a developer I don't really see it.

EDIT: Now, there are specific APIs you can use for TouchWiz (Samsung Android devices) or MotoBlur (for Motorola devices) or HTC Sense (HTC android devices) but those are specific manufacturers based APIs that are meant to tap into their specific UI abilities of their Android modifications. But even that's not a problem. You can choose to use it or not and you can check whether or not an Android device is supporting any of those APIs before you use them.

[+Vice]

techbeck, on 04 May 2012 - 19:19, said:

That was RIM BS that was being tossed out. RIM called android a cesspool concerning piracy.

That is not accurate at all. Many developers have spoken out about the insanely high piracy rates on Android and some of those have said they are no longer willing to develop apps for the platform as a result. This article in Wired posted just one day ago shows a developer that had a 90% piracy rate of their brand new football manager game on Android. http://www.wired.com...id-game-piracy/

[Hell-In-A-Handbasket]

Boz, on 04 May 2012 - 19:54, said:

various devices and different resolutions due to the way they designed it, not because Android is fragmented.

That's what people mean by fragmented.

And you say it's not, yet Epic and a host of AAA Developers say it is. You keep saying your a developer, what have you developed? Have you just downloaded the SDK, or actually published something

As far as FlipBoard, I would have to say its just a staggerd launch, why they are spitting up the devices like they are. Because I think the majority of stuff is server side the actual app has to do verry little. If they did all devices at once, I feel the increase in load would put their servers down, from day 1 they didn't like that thought.

What they are doing now is the same as when they brought out the app for IOS, except with iOS they couldn't hold off devices and had to do invites, as for iOS they were all the same, where with android they can limit it based on device instead of signups

*edit - and FlipBoard doesn't use Absolute layouts, the layout is dynamic based on the content it's pushing. Even changing each time it's opened. So it can't be how you think it is working.

[HawkMan]

Boz, on 04 May 2012 - 20:07, said:

Based on what? I am building Android apps. I never had a problem with any of the apps to run on various Android devices. The only limitation is where you target a minimum SDK which today is really Android 2.x. And there are things like Android Compability Libraries that work ICS 4.0 APIs (http://developer.and...ty-library.html) that allows you to use ICS features and code that works fine on older versions of Android too (it even goes down to Android 1.6).

Tell me specifically why they would have problems? Give me examples. Because from my perspective as a developer I don't really see it.

EDIT: Now, there are specific APIs you can use for TouchWiz (Samsung Android devices) or MotoBlur (for Motorola devices) or HTC Sense (HTC android devices) but those are specific manufacturers based APIs that are meant to tap into their specific UI abilities of their Android modifications. But even that's not a problem. You can choose to use it or not and you can check whether or not an Android device is supporting any of those APIs before you use them.

Density independent pixels and scalable graphics and all that are great, if you don't care about your app looking like **** and conforming to different size devices.

For a good app it needs to be specifically designed for the device, for high res devices you need the proper size images for the proper size "buttons", then some of those devices with the same res can be up to 2 inches different in size, so one of them would have fewer and bigger but higher density thumbs which needs to be coded, but can to some degree be done with intelligent scaling algorithms.

Tis same problem recurs with every different resolution and screen size. Resolutions reasonably close can be fit into the same GUI, just be using flow and filling in white space and padding. But you gave to take physical screen size into account separately. A 3.5 inch device and a 4.5 inch device with the same res can't use the same layout, either one would have to big buttons or the other to small, or one would have to much padding while the other the icons would be on top of each other, one would have shap graphics, the other blurry.

Vectors would fix some of these problems, but they wouldn't work for flipboard and it's graphics anyway. And would just fix the blurriest, not the size and screen size and layout issues.

[z0phi3l]

iKenndac, on 04 May 2012 - 08:21, said:

Exclusive to the Galaxy SIII? WTF? Android really doesn't need forced fragmentation due to business deals like this on top of the fragmentation issues that already exist

The day the GS3 hits the public the APK for Flipboard will go out to the public too, the beauty of Android, we can get around pesky things like exclusivity fairly quickly, even if it has any code to try and keep it on the GS3, it will be bypassed fairly quick.

[Boz]

HawkMan, on 04 May 2012 - 20:34, said:

Density independent pixels and scalable graphics and all that are great, if you don't care about your app looking like **** and conforming to different size devices.

For a good app it needs to be specifically designed for the device, for high res devices you need the proper size images for the proper size "buttons", then some of those devices with the same res can be up to 2 inches different in size, so one of them would have fewer and bigger but higher density thumbs which needs to be coded, but can to some degree be done with intelligent scaling algorithms.

Tis same problem recurs with every different resolution and screen size. Resolutions reasonably close can be fit into the same GUI, just be using flow and filling in white space and padding. But you gave to take physical screen size into account separately. A 3.5 inch device and a 4.5 inch device with the same res can't use the same layout, either one would have to big buttons or the other to small, or one would have to much padding while the other the icons would be on top of each other, one would have shap graphics, the other blurry.

Vectors would fix some of these problems, but they wouldn't work for flipboard and it's graphics anyway. And would just fix the blurriest, not the size and screen size and layout issues.

Nothing you said here makes any sense because "problems" you describe don't exist. You cab include graphics and visuals depending on what type of pixel density the display is and provide assets for that specific density.

ADT is pretty well thought out and provides great environment in development. Android devices are split into 3 categories: high density, medium density and low density and you can include assets for you specific designs and UI based on those 3 categories if you choose so. This is not by any means a must. You can always include assets and UI elements for higher density devices and they will scale down to other vsrsions the same way it works on iOS.

You don't have to code anything in that regard.

Stick to opinions because trying to argue something that you just off-handedly read somewhere online makes you look silly.

[Hell-In-A-Handbasket]

z0phi3l, on 04 May 2012 - 20:49, said:

The day the GS3 hits the public the APK for Flipboard will go out to the public too, the beauty of Android, we can get around pesky things like exclusivity fairly quickly, even if it has any code to try and keep it on the GS3, it will be bypassed fairly quick.

Agreed, friend ran some program and changed the ID of his phone so he could put Netflix on it when Netflix first came out. I though that was Awsome.

[HawkMan]

Boz, on 04 May 2012 - 21:01, said:

Nothing you said here makes any sense because "problems" you describe don't exist. You cab include graphics and visuals depending on what type of pixel density the display is and provide assets for that specific density.

Yes you can, but that's still a lot more work. And doesn't solve the different sizes problem.

Either way, your argument is that developing for 20 different resolutions, and 20 different screen sizes and at least 3 different screen size ratios isn't more work. But your argument still include a lot more work. Just less work than if google hadn't made a good dev tool. It's still a lot more work, just not as much as it would have been.

Writing self contradicting argument only makes you look silly.

[Boz]

HawkMan, on 04 May 2012 - 21:20, said:

Yes you can, but that's still a lot more work. And doesn't solve the different sizes problem.

Either way, your argument is that developing for 20 different resolutions, and 20 different screen sizes and at least 3 different screen size ratios isn't more work. But your argument still include a lot more work. Just less work than if google hadn't made a good dev tool. It's still a lot more work, just not as much as it would have been.

Writing self contradicting argument only makes you look silly.

I'm not contradicting myself. You are jumping from one topic to another. I said, the reason they have more work and delay is because they designed the app for a single resolution and thus now have more work to do it properly on Android that supports multiple resolutions on various devices.

When you design and develop for Android initially it's not more work because you setup and design your app to the way you should on Android to accomodate different resolutions. You don't develop app for 3 different densities and code that way. That would be silly and usually happens when people developed something for a fixed resolution and are now trying to convert it to Android's way.

Different resolutions are not fragmentation. That's like saying, Windows and OSX development is fragmented because different Macs running OSX run with different resolutions. It's absurd.