| Date: 11/07 | Title: Project 3 Teams |
Section 501
1: Achtenberg, Brooks, Grathwohl, Stone
2: Macias(503)Ballew, Daniels, Ray, Willis
3: Goble, Jack, Lawless, Olivieri
4: Joe, Knight, Krieger(503), Percival
5: Scott, Tran(503), Zheng, Oats(502)
6: Bagott, Gates(502), Mooreman, Weaver
7: Garcia, Labastida, Leugemors, Shaw,
8: Both, Hwang, Ogletree, Plamin
9: Orndorff, Sandell, Sathya, [new: Solis(502)]
Section 502
10: Castillo, Fisher, Wu, X-Zhao, [new: Faruqui]
11: Haines, Taylor, Wilson, W-Zhao(audit), Yang
12: Davis, Enriquez, Medeiros, Munoz, [new: Nemec]
13: Ballew, Faruqui, Nemec, Solis
Section 503
14: Davis, DeBolt, Hernandez, Mathew
15: Frazer, Jetton, Martinez, Sitzman
16: Elliot, McWilliams, Rodriguez, Yang
17: Carthel, Huston, Lindstrom, Ali-Saleh
18: Kirchenbauer, Lyles, Tan, Miranda
19: Chepey, Christian, Kirkland, Myers
20: Daniels(501) Macias, De La Garza, Eckenrode, Peters
|
| Date: 11/02 | Title: Android updates (contributed by Casey Brooks) |
Updates on more recent changes in Android API, contributed by Casey Brooks
-
The layout attribute "fill_parent" has been changed to "match_parent".
It is handled the exact same way, but it is more clear to users.
"fill_parent" has been deprecated since API 8 in May 2010.
-
The menu no longer appears as a block at the bottom of the screen, and
is no longer opened by a menu key (for most devices). Google does not want
a hardware menu key, and instead replaces it with a "three-dot-overflow"
button in the ActionBar, which opens as a list. The callbacks are the same,
but having the menu open on the bottom of the screen has been deprecated
since the introduction of the ActionBar in API 11 in February 2011, and
the ActionBar was just changed last month to the Toolbar with API 21.
While the actual implementations are different, I believe it is important
for developers to know the purpose of a Toolbar-like element on screen for
application interaction. You may also want to look into the Navigation
Drawer style of top-level navigation within an app, which works
with the ActionBar.
-
As for the IDE, Google has been developing Android Studio since May 2013,
and while it is still in beta, it is the official IDE for Android
development. It also changes the package structure of applications slightly
and uses a different build system than Eclipse. Eclipse used ANT, while
Android Studio uses Gradle, so how to build applications and include
libraries in your app when building with Gradle might be different than Eclipse.
-
While applications still need Activities to hold Views and manage the
application lifecycle, they should not be used as the main container for a
screen. Fragments should be used instead, as they are essentially a View
that manages the same lifecycle as an Activity, and so offer much more
flexibility. And when using design structures like the Navigation Drawer or
developing for both tablets and phones, Activities literally cannot do the
things that are required, so Fragments are absolutely necessary. Fragments
were added in API 11 in February 2011.
-
The slides describing ViewGroups mentioned the Gallery layout, which
has been deprecated and replaced by the ViewPager in API 16 in June 2012.
Note that using ListView as part of a layout can be a bit tricky.
-
The Dalvik VM on which Android runs has been replaced by the ART
runtime in API 21 last month.
-
Some basic Android components which are missing from the slides are
SharedPreferences and PreferenceActivity/PreferenceFragment for saving
simple data about how the application is run, like the user setting a time
when a notification should be issued. Android has internal
SQLite databases which can be used for storing user data. Notifications and
widgets are helpful to know about, and Toasts are invaluable for giving
simple feedback to users. ASyncTask is an extremely simple way to add
multithreading to an application, and Android will throw an exception if
network calls are made on the main UI thread, and so all network calls MUST
be done asynchronously.
- Resources:
|
| Date: 10/07 | Title: Project 2 Teams |
Section 501
1: Achtenberg, Brooks, Grathwohl, Stone
2: Macias(503)Ballew, Daniels, Ray, Willis
3: Goble, Jack, Lawless, Olivieri
4: Joe, Knight, Krieger(503), Percival
5: Scott, Tran(503), Zheng, Oats(502)
6: Bagott, Gates(502), Mooreman, Weaver
7: Garcia, Labastida, Leugemors, Shaw,
8: Both, Hwang, Ogletree, Plamin
9: Orndorff, Sandell, Sathya
Section 502
10: Castillo, Fisher, Wu, X-Zhao
11: Haines, Taylor, Wilson, W-Zhao(audit), Yang
12: Davis, Enriquez, Medeiros, Munoz
13: Ballew, Faruqui, Nemec, Solis
Section 503
14: Davis, DeBolt, Hernandez, Mathew
15: Frazer, Jetton, Martinez, Sitzman
16: Elliot, McWilliams, Rodriguez, Yang
17: Carthel, Huston, Lindstrom, Ali-Saleh
18: Kirchenbauer, Lyles, Tan, Miranda
19: Chepey, Christian, Kirkland, Myers
20: Daniels(501) Macias, De La Garza, Eckenrode, Peters
|
| Date: 09/02 | Title: Project 1 Teams |
Section 501
1: Achtenberg, Brooks, Grathwohl, Stone
2: Macias(503)Ballew, Daniels, Ray, Willis
3: Goble, Jack, Lawless, Olivieri
4: Joe, Knight, Krieger(503), Percival
5: Scott, Tran(503), Zheng, Oats(502)
6: Bagott, Gates(502), Mooreman, Weaver
7: Garcia, Labastida, Leugemors, Shaw,
8: Both, Hwang, Ogletree, Plamin
9: Orndorff, Sandell, Sathya
Section 502
10: Castillo, Fisher, Wu, X-Zhao
11: Haines, Taylor, Wilson, W-Zhao(audit)
12: Davis, Enriquez, Medeiros, Munoz
13: Ballew, Faruqui, Nemec, Solis
Section 503
14: Davis, DeBolt, Hernandez, Mathew
15: Frazer, Jetton, Martinez, Sitzman
16: Elliot, McWilliams, Rodriguez, Yang
17: Carthel, Huston, Lindstrom, Ali-Saleh
18: Kirchenbauer, Lyles, Tan, Miranda
19: Chepey, Christian, Kirkland, Myers
20: Daniels(501) Macias, De La Garza, Eckenrode, Peters
|
| Date: 09/02 | Title: Neat Compiler Trick |
Here's a small trick to make it easier to define tokens and their corresponding
strings. See Steve Oualline, Practical C++ Programming, O'Reilly and Associates, Inc., 1995. pp460-461.
//----------------------------------------------------------------------------
// Using the define trick to generate tokens and their strings
//----------------------------------------------------------------------------
#define _TOK T(_tik),T(_tak),T(_tok),T(_toe)
#define T(X) X
enum TOKTYPE { _TOK };
#undef T
#define T(X) #X
char TOKSTR[4][20]={ _TOK };
// The above is equivalent to
enum TOKTYPE { _tik, _tak, _tok, _toe };
char TOKSTR[4][20]={"_tik", "_tak", "_tok", "_toe" };
|