Thank you very much, Mark Murphy; that was EXACTLY the type of response I was looking for, and it provoked some more thought on my end.
My original idea was to avoid the need for a server. My naive idea was relaying data between devices themselves (ex. user A adds themself to count. This messages/texts user B. This adds user A to user B's list of "participants", and both update their counter. Any future inquiries -- user C -- to A or B will get that list of "participants", and user C will now be able to relay their own addition and removal to A and B). The reason I first dreamt that up was because of current applications such as google talk, messaging, etc. -- correspondence between two devices, which other applications <http://www.youtube.com/watch?v=JUmachL5IW4> have been capable of. For those that may benefit from my case, a problem arises that can be seen when the first user, ever, uses the application. Who does he or she contact when adding themself to the count? They have no one to contact; the need for the server becomes apparent. Thanks again, Mark. You've described my "upper" bound for what I'll need in order to relay that contact information between devices -- and maybe after that, users can maintain a device-centric count. I'll be looking into status.net for that purpose. Have a great day! If you have any more comments or corrections for this newbie, lay 'em on me. -Danny On Sat, May 1, 2010 at 7:30 AM, Mark Murphy <mmur...@commonsware.com> wrote: > Ubuntu Explorer wrote: > > I have more or less the same question. The amount of detail in the API > > is overwhelming for me to choose what is really required for my app. Are > > there specific areas we can focus on that can help us ramp up quickly. > > That is impossible to answer in the abstract. A 3D first-person shooter > is very different from a PDF viewer, which is very different from a > social networking client, which is very different from a tip calculator. > The "specific areas [you] can focus on that can help [you] ramp up > quickly" will vary by what you are building. > > At the risk of sounding self-serving, if you find the documentation > overwhelming, perhaps you need different documentation: > > http://wiki.andmob.org/books > > (in the interests of full disclosure, I wrote some of those) > > > On Sat, May 1, 2010 at 4:27 PM, Daniel Favela <dfav...@gmail.com > > First question: I've done the Hello World and notepad tutorials, as > > well as run through the quick tutorial > > <http://www.youtube.com/watch?v=I6ObTqIiYfE>on youtube by Dan > > Morril. I've also read a bit of the Android fundamentals > > materials. Is this enough experience to make an application like > > the one I'll describe below? > > > > If not, what do you think I should read or try next? If so, > > > > The application I have in mind will be a counter triggered by > > users. A user will add themselves to the count, remove themselves > > from the count, and view the count. > > > > When a user adds or removes themself to the count... > > - if possible, this will update the count on other instances for > > other users/devices > > > > That's my first step for now. The UI will be a ListView showing the > > counts that users have added themselves to (once I create the means > > to have one count, I will easily be able to scale the app to have > > "n" counts). There will be a button to add and remove the user. > > > > Sounds reasonable, right? Please let me know if this sounds > > difficult, especially where the multi-device communication (in > > updating the counter) is concerned. Know of a library that I'll > > have to use, or have some general advice for this? Tell me! :) > > IMHO, you're looking at your problem backwards. > > Your application requires a server, from your description. Focus on > getting the server right first: > > -- how are you planning on sending data to the server? (HTTP via a > REST-style API? XMPP? SMTP? something else?) > > -- where and how are you storing your counts? (SQLite? MySQL? Oracle? > Flat file? memcached? Redis? something else?) > > -- how are you determining who sees what count? (everybody sees > everybody's? something else?) > > -- how are you planning on distributing updates from the server? > (polling by the clients? WebSockets with Comet? SMS? something else?) > > -- what data format will you be using for all of this? (XML? JSON? YAML? > binary payloads via Protocol Buffers? binary payloads via Thrift? > something else?) > > The only part of Android that really comes into play when thinking about > your server are the communication protocols and payloads to/from the > server. In the end, Android can handle just about anything, but there is > more work involved with some compared to others. However, it may be that > you are still better off choosing something that you're already > comfortable with, even if it makes the Android side a bit more complex, > just to make your server work simpler. > > Once you have the server more or less working -- perhaps via a client > technology you are already comfortable with -- then tackle the Android > client. As you say, the client side should not be terribly difficult, > assuming you have a well-designed server. > > IMHO, the majority of your complexity is with the server. The only > reason that would not be the case is if you're going to try to graft > your design onto an existing engine (e.g., you'll use the status.net > microblogging server and distribute count data via "tweets"). > > -- > Mark Murphy (a Commons Guy) > http://commonsware.com | http://github.com/commonsguy > http://commonsware.com/blog | http://twitter.com/commonsguy > > _Beginning Android 2_ from Apress Now Available! > > -- > You received this message because you are subscribed to the Google > Groups "Android Beginners" group. > > NEW! Try asking and tagging your question on Stack Overflow at > http://stackoverflow.com/questions/tagged/android > > To unsubscribe from this group, send email to > android-beginners+unsubscr...@googlegroups.com<android-beginners%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-beginners?hl=en > -- You received this message because you are subscribed to the Google Groups "Android Beginners" group. NEW! Try asking and tagging your question on Stack Overflow at http://stackoverflow.com/questions/tagged/android To unsubscribe from this group, send email to android-beginners+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-beginners?hl=en
