91–100 of 144 posts
Earlier quoted context omitted.
I'm pretty sure the idea is to get more GUI-based, not less. Telling a designer to use vi instead of Eclipse for UI is pretty hilarious.
Telling anybody to use vi at all is pretty hilarious.
It's worth learning, even if you only learn the basics.
I was able to successfully train a designer to use the Android SDK's tools when appropriate, and check in graphical assets. In preparatory meetings I insisted the designer be in the room with the coders and product managers as I explained how Android is different. I taught them all how to use conditional layouts and how to test apps for good practices by changing font sizes to see if they really are geometry-independ…
I'd be interested in reading more about this - I'd love to show it to some designers I work with. At the moment, I'm struggling to get the designers to acknowledge that Android and iOS need to be designed seperately. iOS designs can look pixel-perfect due to having only 2 resolutions to care about (ok, iPhone 5+ have taller screens, but same width) Android is a whole different story.
(whole slide deck is worth looking at)
Elephant in the room = adoption rate of current OS version. "Kit Kat is awesome!!" That's great. Who is using it?
I am. On my Nexus 5. Compared to a iPhone 5s, this runs circles around it. I'm not trying to start a flamewar or anything, but why are iOS devices so slow and clunky, and why is the UI so... fruity? Its just weird.
I've also got an iPad and seriously considered getting a iPhone instead of my Nexus 4 but iOS's poor keyboard i.e. key caps are always uppercase regardless of shift state, it's hunt and peck rather than swype, and the lack of intents were a deal breaker for me.
> Socially, excluding Android users seems almost prejudicial. Unlike Android is difficult, this isn’t about about mere convenience; it’s a value judgment on who is worth designing for. Put uncharitably, the root issue is “Android users are poor”. How about "Android users want a phone, not apps". If you want a phone, you get an Android. If you want apps, you get an iPhone. Look at the stats for web use. In 2012, there…
> Socially, excluding Android users seems almost prejudicial. Unlike Android is difficult, this isn’t about about mere convenience; it’s a value judgment on who is worth designing for. Put uncharitably, the root issue is “Android users are poor”. How about "Android users want a phone, not apps". If you want a phone, you get an Android. If you want apps, you get an iPhone. Look at the stats for web use. In 2012, there…
No, Android user wants apps. iPhone is just expensive as hell. Android is much cheaper alternative. People who want "just phone with browser" usually buy Nokia Asha or feature phone.
> Socially, excluding Android users seems almost prejudicial. Unlike Android is difficult, this isn’t about about mere convenience; it’s a value judgment on who is worth designing for. Put uncharitably, the root issue is “Android users are poor”. How about "Android users want a phone, not apps". If you want a phone, you get an Android. If you want apps, you get an iPhone. Look at the stats for web use. In 2012, there…
No, Android user wants apps. iPhone is just expensive as hell. Android is much cheaper alternative. People who want "just phone with browser" usually buy Nokia Asha or feature phone.
> The other replies were mostly variations on the theme that Android users don’t pay for apps, they don’t have data plans, you can’t monetise them easily, and designers are all iPhone users and don’t really understand Android users … Socially, excluding Android users seems almost prejudicial. Unlike Android is difficult, this isn’t about about mere convenience; it’s a value judgment on who is worth designing for. Put…
Earlier quoted context omitted.
No, Android user wants apps. iPhone is just expensive as hell. Android is much cheaper alternative. People who want "just phone with browser" usually buy Nokia Asha or feature phone.
And your evidence is ... ? It seems to me there are more than enough cheap and crappy Android handsets out there to serve the feature-phone market too.
Earlier quoted context omitted.
> The equivalent of web standards that would allow an Android app to do responsive design in the manner of a web app, devices don't have or respect. Oh, really? Let's take a look shall we: 1. Using new APIs if available and falling back gracefully if not: http://developer.android.com/training/basics/supporting-devi... 2. Adapting your layout and UI to each device based on screen size, density and other features: http…
You posted three links to the android documentation that don't address sedev's point at all. Your first point doesn't address the "falling back gracefully" part. The second part of that example, the ActionBar, which was introduced in ICS, IIRC, only has a community shim. Granted if you want to use a new API that may not have as much community support as the ActionBar, you either code one yourself (strengthening the s…
ActionBar is not a community shim anymore, a compatibility library down to gingerbread is provided and supported by Google: http://developer.android.com/reference/android/support/v7/ap...
As RyanZAG explained, your multiple layout files should only re-organize fragments.
Yes Android dev is hard, with multiple versions, sizes, formats and bugs. But there is documentation, tools and example to adress them. Deal with it.
If you are willing to try again, as so many things have changed since Eclair, you can have a look at this exemple where you will see how you can use new API and a fallback when they are not available: http://code.google.com/p/android-protips-location/source/bro...