Theory
The home screen needs showmanship
The committee's demand list for FestConnect Mobile's home screen reads like a film poster: the 3 event banners should slide past each other on a loop, and the search should live in a proper search bar with the magnifier icon, not your plain EditText.
Three widgets deliver it: an ImageSwitcher for animated image changes, a timer to turn switching into sliding, and SearchView, the search bar Android already built so you would stop faking it.
Theory
ImageSwitcher and its factory
A plain ImageView SNAPS to a new image. An ImageSwitcher animates the handover: old poster slides out, new slides in.
Its one structural oddity: the switcher does not know WHAT it is switching. You must give it a ViewFactory whose makeView() manufactures the ImageView it animates between:
switcher.setFactory(() -> new ImageView(this));
Then pick the choreography: setInAnimation, setOutAnimation (stock ones like android.R.anim.slide_in_left), and change pictures with setImageResource(R.drawable.poster2).
Practical
Poster banner: switcher + timer = slider
public class HomeActivity extends AppCompatActivity {
int[] posters = { R.drawable.garba, R.drawable.coding, R.drawable.robo };
int current = 0;
Handler handler = new Handler(Looper.getMainLooper());
@Override
protected void onCreate(Bundle b) {
super.onCreate(b);
setContentView(R.layout.activity_home);
ImageSwitcher sw = findViewById(R.id.posterSwitcher);
sw.setFactory(() -> new ImageView(this)); // the factory!
sw.setInAnimation(this, android.R.anim.slide_in_left);
sw.setOutAnimation(this, android.R.anim.slide_out_right);
sw.setImageResource(posters[0]);
handler.postDelayed(new Runnable() { // the slider part
@Override public void run() {
current = (current + 1) % posters.length; // wrap: 0,1,2,0...
sw.setImageResource(posters[current]);
handler.postDelayed(this, 3000); // re-post: every 3s
}
}, 3000);
}
}
Theory
SearchView: the bar you stop faking
SearchView ships the whole search-bar experience: magnifier icon, hint text, clear button. Your job is one listener with 2 callbacks:
searchView.setOnQueryTextListener(new SearchView.OnQueryTextListener() {
public boolean onQueryTextChange(String text) { ... } // every keystroke
public boolean onQueryTextSubmit(String query) { ... } // search pressed
});
Change is the live-filter hook: adapter.getFilter().filter(text) narrows the event list as the user types. Submit fires on the keyboard's search action. Both return a boolean: true means "handled, do nothing further".
Recognise the split? change/submit is TextWatcher's onTextChanged plus a commit moment: third telling of the live-search pattern.
Quiz
A classmate wires an ImageSwitcher, skips setFactory, and calls setImageResource. What happens, and why was the factory ever needed?
- Works fine: the switcher creates a default ImageView itself
- Crashes at that first image call: the switcher has no view to put the image into; makeView() was supposed to manufacture it
- Shows the image without animation as a fallback
- Compile error: setFactory is checked at build time
Show the answer
Crashes at that first image call: the switcher has no view to put the image into; makeView() was supposed to manufacture it
The switcher is choreography without a dancer until the factory supplies one: it animates BETWEEN views that makeView() manufactures, and with no factory there is nothing to load the image into: the app dies at the first setImageResource. Option A grants a default that classic ImageSwitcher deliberately lacks (the factory lets you configure scaling and layout of the inner view). Option C invents graceful degradation; option D confuses run time with compile time: the wiring is legal Java, just incomplete. Factory first, animations second, images third.
Think first
Read the slider's clockwork
In the listing, the Runnable calls handler.postDelayed(this, 3000) INSIDE its own run(). Trace 3 ticks: what shows when, and what does the % do? Also: what familiar mistake would calling run() directly be?
Show the answer
Tick 1 (3s): current = 1, coding poster slides in; the Runnable re-books itself. Tick 2 (6s): current = 2, robo. Tick 3 (9s): (2+1) % 3 = 0: the wrap: garba returns, loop forever. The self-re-posting Runnable is Android's idiom for a repeating timer (BCA404's Timer.Tick, hand-rolled). And calling run() directly instead of posting it is BCA403's run-vs-start trap reborn: the code executes once, immediately, on the spot: no scheduling, no loop.
Watch out
Showmanship traps
No factory: the quiz crash: setFactory before anything else.
The immortal timer: a Handler still re-posting after the screen closes leaks the Activity: remove callbacks in onDestroy (handler.removeCallbacksAndMessages(null)).
Filtering on submit only: users expect the list to narrow as they TYPE: wire onQueryTextChange, not just submit.
"ImageSlider" on the exam: name the construction honestly: an ImageSwitcher advanced by a repeating Handler (or a ViewPager): there is no single stock ImageSlider widget in classic Android.
Theory
Composition over invention
Notice what the slider taught: Android did not ship one; you COMPOSED it from a switcher, a timer idiom and the % wrap: which is how most "missing" widgets are built, and a better exam answer than pretending a widget exists. One Unit 1 topic remains: organising the whole crowded app into tabs: TabLayout with FrameLayout, next.
Summary
Key takeaways
- ImageSwitcher animates image changes; setFactory's makeView() must supply the inner ImageView first.
- setInAnimation/setOutAnimation choose the choreography; setImageResource changes the picture.
- A slider = switcher + self-re-posting Handler.postDelayed + (i + 1) % n wrap: composed, not stock.
- SearchView is the ready search bar: onQueryTextChange (per keystroke, live filter) + onQueryTextSubmit (commit).
- adapter.getFilter().filter(text) narrows a list live: the mobile live-search hook again.
- Stop timers in onDestroy or the Activity leaks.
- Memory hook: factory makes the dancer, timer keeps the beat, change beats submit.