Now I dont know if I could finish my project, but it is only for my problems. First because I discovered the Challenger very late, second I got a job that consumes almost my time and third I got 2 years old twin that consumes almost my sleep time :)).
But same I want to thank to everybody here in this group for your advices. Especially to hackbod, Dan U., Megha Joshi and Romain Guy. They are always given a promply anwser with important tips. Thanks to them, thanks to everybody !!! And good luck to Google with this new technology. Jorge. On 7 abr, 23:18, jtaylor <[EMAIL PROTECTED]> wrote: > "That's important for the Android team > and for the Open Handset Alliance and its members, that's important > for Google. That's also important for the developer community and for > the end users." > > Hello Jean-Baptiste, > > I suggest that the aim be for the phones to come out in 2009. If > everyone is patient, then that will be a proof of cooperation. The > Android Team doesn't needs phones for 2008. Neither does the OHA. And > there can be more Developer Challenges. > > More Developer Challenges would appear to be important in two ways. To > perfect Android and also for Google promotion. AT&T seeks to depart > more away from Google apps which is reasonable for them. However, > Google has the Cloud and that Cloud can come out in creative ways > through a couple more Developer Challenges. > > At the risk of being melodramatic, Android is the most important piece > of software in human history. I really don't think it should be > rushed. Everyone should be patient and that Patience will pay off. > > - Juan > > On Mar 29, 12:28 pm, "Jean-Baptiste Queru" <[EMAIL PROTECTED]> wrote: > > > > > (Notice: I'm a Google Software Engineer working on Android). > > > One aspect which I hope is reasonably clear in everybody's minds is > > that getting devices available is really at the top of the priority list for > > everyone involved in Android. That's important for the Android team > > and for the Open Handset Alliance and its members, that's important > > for Google. That's also important for the developer community and for > > the end users. > > > From that point of view, every day that passes without devices out there > > hurts the entire Android ecosystem, and therefore has a high cost. > > Because of that, whenever anyone has to choose between doing > > something that directly helps ship those first devices and something > > that doesn't directly help, the latter option has to carry a very high value > > in order to outweigh for the cost of delaying the first devices. That's why > > the SDK isn't as polished as it could be, that's why Google employees > > aren't as present on those forums as they could be: it would distract > > from the primary goal of shipping devices in 2008. > > > It might sound surprising to many, but Google only has a finite number > > of people who are currently familiar enough with Android to be able to > > make a significant difference on either the ship date or the SDK and the > > developer community. It takes time and it takes money to grow a team, > > Google has a significant amount of money but remains careful about > > how they spend it like any well-managed company, and they can't do > > anything about time: even by having people work hard, there's always > > a limit to how much work any single person can achieve every day. > > > All that explains why you're not seeing dozens of engineers spending > > several hours every day answering questions and helping people on > > the forums, or preparing a new SDK every other week: at the end of the > > timeline toward the first devices, that would result in delays that would > > be counted in weeks or even months. Having to choose is painful, > > because we'd all like to get the best of both worlds. You can't have > > your (proverbial) cake and eat it too, and right now we're a bitstuck > > between a (proverbial) rock and a (proverbial) hard place. > > > Back to the issue of the SDK, I think that you've put the finger on one > > of one of the aspects that are hard to balance: how early and how often > > should it be released. Too early, and developers get some software > > that is too unstable and too far from the final product to be valuable. > > Not early enough, and developers don't have time to get familiar with > > it, provide valuable feedback and have applications ready for the first > > device. Too often, and developers will spend too much time chasing > > porting their code from one release to another and the whole ecosystem > > will be confused about what works and what doesn't in every release. > > Not often enough, and some developers will bestuckfor weeks on bugs > > that may have been fixed but be unavailable. And, like I said earlier, > > "early" and "often" have a negative impact on the ship date. > > > During the software development cycle of a framework, you're likely to > > see 3 phases: bringup, unstable, and stabilization. During the bringup > > phase, the software improves quickly, but it is too rough and too far > > from its final shape to be valuable to many people - this is a phase > > that typically sees frequent releases to a very small number of close > > partners. During the unstable phase, the framework is large enough > > and is used by enough applications that it can't change quite as quickly > > as during the bringup, but it is still getting some very significant > > changes. > > This is the phase during which the release strategy changes from > > frequent limited releases to infrequent broad releases. This is the phase > > that M3 and M5 came from (as an example, you've all seen how the UI > > had changed between M3 and M5). Finally, there's a stabilization phase, > > where the framework gets fewer and fewer changes and gets closer and > > closer to its final shape. That's the phase when there can be frequent > > broad releases, that's the phase during which beta programs happen. > > > What you've seen so far was definitely in the unstable phase, and when > > such a project gets into a stabilization phase is can make sense to > > consider more frequent releases, which in the case of Android must > > be weighed against the impact that such releases can have on the > > final ship date or on the developer challenge. > > > Releasing Android SDKs is harder than it seems while in the unstable > > period, because of the number of people and companies who work on > > it and who therefore need to synchronize their efforts to reach a point > > where every module is reasonable usable at the same time. During a > > stabilization phase when fewer regressions happen, it's easier to pick > > almost any point in time and to use that as a starting point for an SDK. > > > I'll wrap up with a third aspect: a view ahead. Even though there seem > > to be new mobile phones being released all the time everywhere, if you > > look closely things are actually moving fairly slowing in the mobile > > industry. > > Extremely often, a new phone is created by starting with a phone from > > the previous generation, fixing a few bugs and changing the color and > > the shape of the shell. > > > Deep changes happen over much longer timeframes, measured > > in years. How long? Well, the project has been going on for a while > > already, and the goal remains to have the first devices available by the > > end of the year (see the Nov 5 press release). If we assume one major > > release every year (which is typical in this industry), that means that > > there > > will be devices running the initial version of Android with ship dates all > > the way through 2009. If manufacturers take a year to release new devices > > (which is also typical in this industry), we'll see devices running the > > original Android being sold on the top shelves all the way through 2010, > > and they might still be discounted until 2011 (as models from the > > previous year). Once you realize that many devices are used for 2 years > > or more (contracts in the US are often for 2 years), you get to the point > > where you're essentially looking at a 10-year timeline from start to finish. > > That 10-year time scale isn't unique to the original release - in fact I > > have > > worked in the past on major versions 6, 7 and 8 of a mobile framework, > > and each of those went beyond the 10-year mark or is on track to get there. > > > All that means that, right now, as an external developer, you might have > > only seen about 4 1/2 months of the history of Android, and therefore a > > month > > or even a week might seem like a very long time to wait for a new release, > > in > > the big pictures you can count on phones running the original version of > > Android to still be in people's pockets 5 years from now, and on that scale > > a week or even a month isn't that much. On the other hand, a month or even > > a week might be enough to miss the 2008 targets if the devices aren't ready > > on time. > > > JBQ > > > On Sat, Mar 29, 2008 at 4:25 AM, Rui Martins <[EMAIL PROTECTED]> wrote: > > > > The biggest problem think is the lack of synchronization, between > > > what is on the docs and what is on code. > > > Which takes us to scavange the forums for extra info, that might have > > > been "leaked", like "stuff X actually doesn't work as documented". And > > > this steals a lot of development time. > > > > But this is a known problem for ages. > > > > But the 3 or 4 google guys, that do answer developer questions are > > > quite helpful, when the questions are done properly, and when you show > > > you have done your homework. > > > > But yes, I do believe that Google should have deployed more personnel > > > on this SDK. > > > We are being used as "Guinea Pigs", which most of us accept without > > > problems, but that doesn't mean it's not frustrating when we getstuck > > > on some issue, due to lack of info, mostly. > > > > Google should have prepared better for this event. > > > Put probably, some comercial pressure rushed the SDK out of the door > > > before it's time, and all the required infra structures where setup to > > > handle all developers needs. > > > > We don't have a perfect world, so, we have to live with what we have. > > > > But this may have an adverse effect on developers/companies actually > > > adopting Android. And as we all know, for a new product/service to be > > > adopted by the masses, there is a need to overcome the required > > > "critical mass", which might be harder, given the current conditions. > > > > On 27 mar, 14:51, Anil <[EMAIL PROTECTED]> wrote: > > > > Please post your opinion: > > > > For me, I am disappointed. There must be scores of > > ... > > leer más »- Ocultar texto de la cita - > > - Mostrar texto de la cita - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
