Don't forget to...


Friday, April 12, 2013

Above is an activity's lifecycle.

Twitter auth only works if the time on the phone being used is correct.  Sometimes the emulator is way off and then I'll get an error when trying to get authorized.

Twitter resources:

Tuesday, April 9, 2013

OAuth works like the above.  What makes it REALLY difficult to do in android is the constraint that you can only make external calls through an async task (a new thread).  One way to do it with Twitter4j is to setup the Twitter object reference, AccessToken and the RequestToken as globals (ew...) and then use 1 private AsyncTask to call twitter to get the request token, then show the authorize url that's returned so the user can go authorize.  Then ask the user for the verifier, and use it to start another asyncTask to get the accesstoken. 

Monday, April 8, 2013

android tips/notes

APK = Java (src,gen) + Resources (res) = glue between Java and Resources

make a project command-line compileable :
enter project workspace directory
> android update project --name --path .
> ant install ( will fail if no device to run on)
> ant debug (should succeed, as it only compiles a debug version)

info for android virtual machines located in ~/.android/avd/

adb (add sdk/platform-tools to PATH)

adb shell

adb devices, adb -s

To get nexus one working : edit /etc/udev/rules.d/51-android.rules and add
SUBSYSTEM=="usb", ATTR{idVendor}=="18D1", MODE="0666", GROUP="plugdev".

then unhook phone, and restart everything, then allow debugging on phone, and hook it in
and then start eclipse .... that seemed to do the trick

18D1 is the vendor code, i believe for google - don't use the htc one.                             

Services : code that runs in the background (no UI)
Content Providers : share content with applications across application boundaries, e.g. contacts

from project folder :
> adb logcat StatusActivity:* *:s

SETUP TWITTER easy walkthrough :
twitter example :

apparently, android sdk 11 and higher doesn't allow potentially long-running things to happen in the foreground thread because it could lead to the dreaded "application not responding...or w/e" error.  From that I'll get a StrictMode exception - use a lower target version of android OR put the faulty code in an async task in the background.... reference :

Wednesday, April 3, 2013

android setup

Download the adt bundle, then use to start your first app.

Might need to get a device to test on.  Also might need to get the right libraries.

Always start eclipse using ./eclipse -vmargs -Xms1024m -Xmx2048m
( reference : )

AFTER doing all that, you can try using ruboto :

Monday, March 4, 2013

Ruby notes

carlhuda janus

dotfiles repo - create one ( for .bash, .bash_profile, .vimrc etc)
e.g. gary bernhardt - github drb -

rc - resource configuration

intellisense vim - supertab

pry, interactive_editor - irb tools

Getting a ruby/rails environment setup the easy way

Following directions in , I came up with an issue where vagrant box couldn't ping google, and therefore couldn't d/l packages.

solution :

Also,  trouble with nokogiri and/or pg when you do 'bundle update' ?  Checkout and/or .

Notes on Effective Java 2nd Edition

Chapter 3 - Methods Common to All Objects
  •  Item 8: Obey the general congract when overriding equals - page 33
    • If you decide to implement equals, make sure it is
      • reflexive: for all x, x.equals(x)
      • symmetric: for all x & y, x.equals(y) iff y.equals(x)
      • transitive: for all x, y, z, if x.equals(y) and y.equals(z), then x.equals(z) must be true
      • consistent: for all x & y, multiple invocations of x.equals(y) return the same result provided nothing used in equality is changed in either x or y
      • for all x, x.equals(null) must return false
  • Item 9: Always override hashCode when you override equals
  • Item 10: Always override toString
  • Item 11: Override clone judiciously
  • Item 12: Consider implementing Comparable
Chapter 4 - Classes and Interfaces
  •  Item 13: Minimize the accessibility of classes and members
    • accessibilities
      • private
      • package-private (default)
      • protected
      • public
    • classes with public mutable fields are not thread-safe
  • Item 14: In public classes, use accessor methods, not public fields
    • if a class is accessible outside its package, provide accessor methods to preserve flexibility
    • if a class is package-private there is nothing inherently wrong with exposing its data fields
  • Item 15: Minimize mutability
    • to make a class immutable:
      • Don't provide any methods that modify the object's state
      • Ensure that the class can't be extended
      • Make all fields final
      • Make all fields private
      • Ensure exclusive access to any mutable components
    • immutable objects are simple, inherently thread-safe and can be shared freely
  • Item 16: Favor composition over inheritance
    •  Inheritance violates encapsulation
    • Inheriting from another class propagates any flaws that were in the superclass
    • Use composition and forwarding instead
  • Item 17: Design and document for inheritance or else prohibit it
    • If a class is meant to be inherited from, the class must document it's self-use of overridable methods
      • state in a method comment, which overridable methods it invokes
    • The only way to test a class designed for inheritance is to write subclasses
      • therefore you must test your class by writing subclasses before releasing it
    • constructors must not invoke an overridable method - pg. 90
    • It's best to prohibit subclassing in classes that are not designed and documented to be safely subclassed
      • either make the class final
      • or make all the constructors private or package-private
  • Item 18: Prefer interfaces to abstract classes
    • A class can only extend 1 abstract class, but can implement multiple interfaces
    • Existing classes can be easily retrofitted to implement a new interface
    • Interfaces are ideal for defining mixins, abstract classes cannot
      •  mixin: a type that a class can implement in addition to it's primary type, to declare it has some optional functionality
    • Interfaces allow for the construction of nonhierarchical type frameworks
    • Interfaces enable safe, powerful functionality enhancements
      • via the wrapper class idiom
    • You can combine the virtues of abstract classes with interfaces by providing an abstract skeletal implementation class to go wit heach nontrivial interface that you export
      • by convention, skeletal implementations are called AbstractInterface (e.g. AbstractSet, AbstractCollection, etc.)
      •  because skeletal implementations are designed for inheritance, obey the rules of Item 17
      • example page 95
      • simulated multiple inheritance : create a skeletal implementation of an interface, then create another class that has an instance of a private innerclass that extends that skeletal implementation
    • 1 major advantage of abstract classes : they are far easier to evolve than interfaces
      • to add a method to an abstract class, just add it with a reasonable default implementation - then the inheriting classes can override it in due time
      • interfaces, however can never have a method added without breaking pre-existing implementations
        • because of this, the programmer must get it right the first time, before it's released into the wild
    • Interfaces are generally the best way to go
      • the exception is when ease of evolution is deemed more important than flexibility and power
  • Item 19: Use interfaces only to define types
    • The constant interface anti-pattern is a poor use of interfaces
      • it is an implementation detail that becomes visible to clients
      • subsequent releases of a class that may no longer need the constants must continue implementing the interface to ensure binary compatibility
  • Item 20: Prefer class hierarchies to tagged classes
    • tagged classes(example pg. 100) are verbose, error-prone and inefficient
    • a tagged class is just a pallid imitation of a class hierarchy
  • Item 21: Use function objects to represent strategies
    • function object: an instance of a class whose methods perform operations on other objects (e.g. comparator)
    • a primary use of function pointers/objects is to implement the Strategy Pattern
  • Item 22: Favor static member classes over nonstatic
    • a nested class should exist only to serve its enclosing class - if it's useful outside that class, it should be a top-level class
      • 4 types: static member classes, nonstatic member classes, anonymous classes, local classes
        • all but the 1st are inner classes
        • each has it's use (page 108, end)
    • If you declare a member class that does not require access to an enclosing instance, always put the static modifier in its declaration
      • not doing so forces instances to store a reference to it's eclosing class, which wastes space and time
Chapter 5 - Generics (page 109)
- useful generics vocabulary chart on page 115
  • Item 23: Don't use raw types in new code
    • generics are safe, raw types are not
      • this is because the compiler will tell you if you're using a type where you shouldn't be rather than finding out at runtime
    • Set<?> can contain objects of some unknown type (safe)
    • Set<Object> can contain anything (unsafe)
  • Item 24: Eliminate unchecked warnings
    • Eliminate all unchecked warnings if you can
    • If you can't eliminate a warning, and you can prove that the code is typesafe, then and only then, suppress the warning with an @suppressWarnings("unchecked") annotation
      • Always use suppressWarnings on the smallest scope possible
      • Always add a comment saying why you used it
  • Item 25: Prefer lists to arrays
    •  Arrays are covariant(Object[] is a supertype of String[]) , Lists are invariant(better - can't add objects of typeA to a list of typeB - compile time error
    • Arrays are reified (enforce types at runtime and not at compile time) and generics are implemented by erasure (enforce types at compile time but not at runtime - allows for backwards compatibility with older Java version code)
    • Better to enforce and find out of issues at compile time
  • Item 26: Favor generic types
    •  Fewer errors discovered at runtime - they'll be discovered at compile time
    • If using arrays, can't generically type them, so might need to use type casting (pg126 example)
  • Item 27: Favor generic methods
    •  generic methods use type inference to figure out the type of the invocation
    • generic static factory method (pg131)
    •  type parameters can be bounded by an expression that involves that type parameter itself
      • e.g. <T extends Comparable <T>>
        • this reads 'for every type T that can be compared to itself'
      • pg 133
  • Item 28: Use bounded wildcards to increase API flexibility
    • for maximum flexibility, use wildcard types on input parameters that represent producers or consumers 
      • if a type is both a producer and consumer, wildcards are useless
    • PECS - producer-extends, consumer-super
    • use wildcards so that you can use any subtype of a certain type in a list
      • e.g. stack.pushAll(Iterable<? extends E> src) { for(E e: src)...}
      • pg. 135
    • use wildcards so that you can require a method parameter to be able to store a generic type
      • e.g. stack.popAll(Collection<? extends E> dst) { ...dst.add(pop())}
      • pg. 136
    • do not use wildcard types as return types - it only causes the client code to have to use wildcard types and provides no additional flexibility
    • properly used, wildcard types are nearly invisible to a class' users
    • rarely, explicit type parameters are necessary
      • e.g. Set<Number> numbers = Union.<Number>union(integers, doubles);
    • Comparables and Comparators are always consumers (pg. 138)
      • always use Comparable<? super T> in preference to Comparable<T>
      • always use Comparator<? super T> in preference to Comparator<T>
      • e.g. public static <T extends Comparable<? super T>> T maxOf(List>? extends T> list)
  • Item 29: Consider typesafe heterogeneous containers
    •  The Class class has a generic method for casting safely
      • public class Class<T> { T cast(Object obj); }
    • The Class class has a method to cast to a subclass
      • someClassObj.asSubclass(Annotation.class);