Highest Rated Comments
b1ackcat89 karma
I feel like that should be illegal....or encouraged, depending on which end you're on. I had a Calc 3 prof who was a visiting scholar. He was here doing research and had no interest in teaching the class he was assigned. 4 questions per exam. No partial credit. IN CALCULUS. Needless to say, the failure rate (a 0.0 score which meant < 50% of total class points) was OVER FIFTY PERCENT. He left after the semester was over, and all 20 of us had to pay to retake calc 3.
I fucking hate our math department.
</rant>
b1ackcat88 karma
Android dev here looking for something to fill the hours. If you ever need a hand or just want some advice, feel free to PM me. Android can be tricky as hell sometimes, and there's a huge slew of third party libraries and tools that you won't know you really want when just starting.
b1ackcat56 karma
Have you guys discussed writing mobile apps to act as more robust controllers? I've had a whole slew of issues off and on with the browser page for a controller. Lag resulting in missed turns, buttons not appearing, etc. I'm sure a great deal of that can be attributed to server load, but having a local app to take care of rendering the UI would probably help, and make for a better user experience.
Either way, love the games!
b1ackcat45 karma
Just a suggestion - you may want to break up that e-mail address so it's not a hyperlink. Bots scan for that kind of thing and you may inadvertently be bringing lots of spam to your booker's inbox.
With that out of the way, I don't have any questions, but I saw you live in Ann Arbor a couple years ago and you were fantastic. Thanks for the show!
b1ackcat166 karma
To expand on /u/BestSanchez 's great answer:
ButterKnife - Dependency injection for android View objects. When you're holding references to your View objects in your code (i.e. the XML representing your UI that you reference to populate data fields, write labels, etc), you have a ton of boilerplate code in your OnCreate methods binding your member variables to those fields via FindViewById() calls. ButterKnife makes this (among other things) much less verbose while also being (imo) more readable, by allowing you to use annotations on your member variables to reference the views, replacing all the binding FindViewById calls with a single ButterKnife call to kick things off.
Gson - JSON parser
AppCompat/Support Libraries - Probably the most important item in this list. You should absolutely at all times be using AppCompat over the standard built-in activity/fragment classes unless you have a very specific reason not to. Not only do they provide backward compatibility to features introduced on later versions for previous versions of Android (i.e. API 16 features on API 14 devices), but they also have a slew of bugfixes and additional features to make using Activities/fragments a bit less painful.
Retrolambda - A god-send of a tool which allows you to use lambda expressions in Android's Java environment. Android uses a pretty outdated version of Java (the API is closest to Java 6 with some parts of Java 7 as well). This means by default, no lambda expressions (a Java 8 feature). This library hooks into the build process to allow you to use lambdas, which GREATLY decreases the amount of boilerplate, especially when coding against Android's very Listener-pattern-heavy APIs.
OkHttp/Retrofit are used in making handling web requests much more streamlined, but I've never used them so I can't speak to them much. They're definitely the go-to recommendation for that sort of work, though.
I would also add:
RxJava (ADVANCED) - Not something to look into right away, but something to think about digging into once you're more comfortable with Android. The Reactive X (Rx) framework are a set of libraries built in several languages which are designed to make handling streams of data over multiple threads a much simpler process. However, Rx has a very steep learning curve and it's very easy to do things wrong if you're not careful, resulting in confusing errors that can be hard to debug. Bug once you have your "a-ha" moment, you can turn the 3+ sets of classes usually required for something like reading from the network/local IO on a background thread then populating the UI with the result into literally a dozen or so lines of code.
RxAndroid - A helper library for use with RxJava, which adds additional capabilities to make RxJava play nicely with Android with even less boilerplate.
Having said all that, I do think there's some value in writing a handful of test/demo apps the pure "android" way just so you get a feel for what's going on in the environment. Then after you've done a couple of those and get sick of the ridiculous amount of boilerplate and edge cases pure android has you deal with, start looking at the available 3rd party tools to abstract those pain points away.
EDIT: Added RxAndroid
Edit2: Thanks /u/knockoutn336, I did indeed mean OnCreate
View HistoryShare Link