Forem: David

Quick Example of Abstract Classes in TypeScript

David — Fri, 15 Sep 2023 04:00:36 +0000

In this example we abstract a Card class so we can have Playing cards or Joker Cards
If we were to go further we could create a Game class that accepted one or more of the Card types depending on the game, blackjack, poker, war, etc…

Interfaces are not required for abstract classes, but can be useful for setting up a root blueprint

interface ICard {
  value: number;
  getValue: ()=>number;
  compareTo: (o: ICard) => boolean;
  toString: () => string;
}

Abstract class can instantiate its own methods and variables or declare them as required for classes that extend from it.

abstract class Card implements ICard {
  value: number;
  constructor(value: number){
    this.value = value;
  }
  getValue(){
    return this.value;
  }
  compareTo(o: Card){
    return this.getValue() > o.getValue();
  }


  // abstract keyword is used to tell classes that extend this class
  // that they have to implement this method
  abstract toString(): string;
}

// Enum is just for setting the type in the next class PlayingCard
enum SUIT {
  Diamonds,
  Clubs,
  Spades,
  Hearts,
}

Extending an abstract class means we only have to implement the methods of Card that are marked abstract after that we can customize the methods to fit our needs

class PlayingCard extends Card {
  suit: SUIT;

  constructor(value: number, suit: string){
    // since we are extending an abstract class we need to instantiate the   
    // Card class in the constructor with super();
    super(value);
    this.suit = this.convertStringToSuit(suit);
  }

  private convertStringToSuit(suit: string){
    switch(suit){
      case "Diamonds":
        return SUIT.Diamonds;
      case "Clubs":
        return SUIT.Clubs;
      case "Spades":
        return SUIT.Spades;
      case "Hearts":
        return SUIT.Hearts;
      default:
        throw new Error();
    }
  }

  private convertSuitToString(){
    switch(this.suit){
      case SUIT.Diamonds:
        return "Diamonds";
      case SUIT.Clubs:
        return "Clubs";
      case SUIT.Spades:
        return "Spades";
      case SUIT.Hearts:
        return "Hearts";
      default:
        return "";
    }
  }

  toString(): string {
    return String(this.getValue()) + " of " + this.convertSuitToString();
  }
}

A new class based on Card class that has a unchanging value, but its own color method
class JokerCard extends Card {
  color: string;
  constructor(color: string){
    super(14);
    this.color = color;
  }

  toString(): string {
    return String(this.value) + " " + this.color;
  }
}

Instantiating and using both of the classes example

Card is the Abstract class so now we can technically store multiple types of Card objects into a single array

const cards: Card[] = [];
cards.push(new PlayingCard(1, "Diamonds"));
cards.push(new JokerCard("Black"))

Due to shared Logic between the abstract class Card and PlayingCard and JokerCard the compareTo method is available for comparing the playingcard and JokerCard class

console.log(cards[0].compareTo(cards[1])); 
// returns false as 1 is not greater then 14

The toString method is also allowed no matter which class object as both were required to implement it.

console.log(cards[0].toString()) 
// prints "1 of Diamonds"
console.log(cards[1].toString()) 
// prints "14 Black"

I’ve also implemented this in an online editor to see the working example and edit it goto Card abstractions

Thoughts about IOS and Android Native development

David — Fri, 04 Feb 2022 10:07:34 +0000

In Oct of 2019 I passed the Google Android Developer Certification Test. I was super excited at the time as it would help open doors to many high paying Android jobs, so I kept constantly building apps to boost my portfolio.

The first job offer I accepted however was not in Android, it was with React and while I tried hard to keep building Android apps when I had free time, It slowed down greatly.

Then in 2021 a local non profit business came to me with an interesting proposition for an app they wanted. This app would require me to design layouts, implement a backend, and finally after all this time work in Android again. There was a catch though I also had to build an IOS version for their Iphone clients. So the following list is a few of my thoughts regarding Android and IOS and the possibility of a multiplatform tool.

Update(11-29-2022) System Design Note

This project uses a 2 layer distributed architecture with client side caching, remote Authentication and document based persistent datastore Firebase allowing for Horizontal scaling and growth.
Built to handle 3000 concurrent users or approximately 200 unique teams per Geographical region.

Multiplatform thoughts

Kotlin multiplatform appears great on the surface, but that is only if you are using it like a backend service for fetching, storing and sending data. As soon as I tried to use libraries designed to supoort either Android or IOS native there were lots of road blocks and a large lacking of documentation for implementing them with kotlins multiplatform.
React native and flutter would have been an ok choice, but they do have a lot less control of what you can do with the apps and occassionally you need native platform level depth quality and they just didn't have it.

Native Platforms for Android and IOS thoughts

SwiftUI/IOS

Love this language and documentation, its object oriented and has a plethora of examples making it very easy to find what you need most of the time.
Probably should have refreshed myself with the kotlin/android side of phone apps before jumping into IOS. The biggest reason being patterns and principles can be applied accross platforms when the platforms are similar and your knowledge is up to date.
SwiftUI doesn't always let you know when and why a library feature was deprecated, so supporting multiple software versions of IOS can become tricky. Especially if they haven't updated official tutorials from apple regarding that libraries usage.
I really like the swiftui preview, but during minor errors like syntax and not seeing it update can be frustrating since they can hide the errors even after hitting rebuild.
Not having a local db for IPhone like Android can, was surprising. Swifts struct and Observable pattern is great when you get used to it, but coming from the Android side of things it felt like magic for a while for persisting data between pages.

Android/Kotlin

I chose Kotlin as it was becoming more popular and compiles down into Java, I can say I am fairly impressed at how much simplier it was then using pure Java.
After having a fairly good time with swiftui, I became frustrated with some of Androids methods, especially the build dependencies needed to use jet pack libraries, which I thought would be part of the Android ecosystem by now.
Libraries are becoming a pain to deal with, there is a major repo that is forcing everyone to convert their artifacts to a new location because they are shutting down, and since the most popular libraries haven't migrated for some tools its hard to find replacements.
Documentation regarding patterns, I like the MVVM pattern and learned it from Google's tutorials and as I was implementing, my app kept kept getting more complicated so I tried out other patterns like repository pattern alongside of MVVM. the biggest issue with some of the new patterns is they are limiting, if I use the repository pattern to handle network calls and update my local DB it becomes difficult to notify my user when an error has occurred. Of course you can pass down fragment application context to the repository in order to populate toasts, but at that point I might as well just be doing the network call closer to the fragment in the View Model. So in summary the patterns can be useful, but tutorials should be more in-depth with real world practices to overcome the limits of said pattern.

Bonus Firebase/Firestore, Google Analytics, and Google Admobs

Firebase is a really nice site that allows you to see your backend services easily.
Firebase authentication and library helpers is well documented for both IOS and Android making it quick to implement.
Firestore takes a minute to learn, but after getting used to a document storage instead of pure sql is and the helpers it provides for protecting your DB, it is something I would recommend all phone app developer to use.
Google analytics sounds great but does almost nothing for helping find real time crashes, apparently you have to sign up for crashalytics seperately and may not even be worth it without the custom log statements from google analytics.
Admob is an interesting service, I liked how easy it was to implement in a central location on SwiftUI/IOS but I didn't like how on Android I was re-typing my admob unique key in multiple places.

Thank you for reading

I appreciate you taking the time to read, these are just some of my thoughts I wanted to write out as I am coming up to the completion of my current project and it felt nice to get them off my chest.

A great blog post about senior programmer roadblocks

David — Fri, 04 Feb 2022 09:24:21 +0000

https://levelup.gitconnected.com/this-is-why-most-programmers-fail-to-become-senior-developer-143bc8c1342d

Mediator Pattern Self Created Documentation

David — Mon, 18 Jan 2021 04:32:58 +0000

About Mediator

Mediator is a UI/UX pattern for building components and interacting with Api Calls, by using the Mediator pattern the UI/UX can maintain a micro-service architecture for easier testing and reusability.

Graph Representation of Data Flow

In this example we have both the GRPC Api and a mock Api which imitates the GRPCApi. This allows us to test our components and logic without having to repeatedly hit the backend methods by simply calling the MockApi instead.

ApiMediator Example

The ApiMediator is where we define our class definition and functions. Below is an example implementation.

export class AnimalMediatorExample {
  private api: AnimalApi;
  animal = new AsyncActionRunner({name: "cat", legs: 4});
  changedAnimalsCount = new ObservableValue(0);

  constructor(api: AnimalApi){
    this.api = api;
  }
  getBigCat() {
    const action = new AsyncAction(()=>{
      const [request, cancel] = this.api.getBigCat(); // returns Promise.resolve({name:"lion", legs: 4});
      action.onCancel(cancel); // optional method
      return request;
    });

    changedAnimalsCount.setValue(changedAnimalsCount().getValue()++);

    return this.animal.execute(action);
  }
  getSmallCat() {
    const action = new AsyncAction(()=>{
      return this.api.getSmallCat(); // returns Promise.resolve({name:"bobcat", legs: 4});
    });

    changedAnimalsCount.setValue(changedAnimalsCount().getValue()++); 

    return this.animal.execute(action);
  }
}
...

AsyncActions: extend the functionality of Promise, they are able to retry and cancel the execution.

AsyncActionRunner: extends ObservableValue to handle only Asynchronous Values.
To do this it executes AsyncActions and notifies any party of the status of that action. AsyncActionRunner stores the following properties:

status: "initial" | "pending" | "success" | "error" | "disabled"
value: { name: string, legs: number } // From AnimalMediatorExample
error: any

These properties can be updated indefinitely, and can be subscribed to in the the components.
For more information on Observables and Subjects see RxJs

note: AsyncActionRunner does trigger component re-renders every time it updates.

ApiProvider Example

import React, { useMemo, useEffect } from 'react';
import { AnimalMediatorExample } from './AnimalMediatorExample';
import { MockApi } from './MockApi';
import { IApi } from './IApi';

export const AnimalContext = React.createContext(new AnimalMediatorExample(new MockApi()));

export interface Props {
  children?: React.ReactNode | React.ReactNode[];
  api?: IApi;
}

const AnimalProvider = ({ api, children }: Props) => {
  const mediator = useMemo(() => {
    if (api != null) {
      return new AnimalMediatorExample(api);
    } else {
      return new AnimalMediatorExample(new MockApi());
    }
  }, [api]);

  useEffect(() => () => mediator.dispose(), [mediator]);

  return (
    <AnimalContext.Provider value={mediator}>{children}</AnimalContext.Provider>
  );
};

export default AnimalProvider;

In the AnimalProvider we create a Context that can be passed to any children components, this is similar to instantiating the class AnimalMediatorExample and saving it to a local const so that we can access the properties and functions.

React Example Usage for AnimalProvider

import React from 'react';
import AnimalProvider from './AnimalProvider';
import CatComponent from './CatComponent';

const AnimalProviderWrapper = () => {
  return (
    <AnimalProvider> //or can pass in as a prop an Api to override the MockApi <AnimalProvider api={AnimalApi}>
      <CatComponent />
    </AnimalProvider>
  );
};

This would ensure that <CatComponent /> has access to the AnimalMediator context.

More information on React Context can be found here

Functional Components Using Mediators Data from Context Provider Example

import React from 'react';
import { useAsyncValue } from '@operator/shared/utils/mediator/hooks/useAsyncValue';
import { AnimalContext } from './AnimalProvider.tsx';

const CatComponent = () => {
  const mediatorContext = React.useContext(AnimalContext);
  const bobCat = useAsyncValue(mediatorContext.getSmallCat()); //useAsyncValue returns the value insde of the promise { name: 'bobcat', legs: 4 }
  return (
    <div>
      <p>I Have a pet {bobCat.name}</p>
    </div>
  );
};

note: useAsyncValue is a custom hook built to retrieve the value inside of a Promise

Notes on writing Tests for components

Jest will occasionally throw a strange error with our new mediator pattern, the error details are usually not very clear but a few things that can help clear up where the problem is coming from is by wrapping the test component in a context and ensuring it is provided a mockapi.

const mockApi = {
  getSmallCat: jest.fn().mockImplementation(() => [Promise.resolve(), () => {}]),
  getBigCat: jest.fn().mockImplementation(() => [Promise.resolve(), () => {}]),
};
test('Should Display Animal Component', () => {
  render = (
    <AnimalProvider api={mockApi}>
      <CatComponent />
    </AnimalProvider>
  );
...

Mediator Principles

Single Responsibility Principle

Mediators should have one responsibility and do it well.

YAGNI -You aint gonna need it

Mediators don't need a bunch of type converters to pass the data to the component. I've noticed adding to many converters and methods clutters up the simplicity of the mediator pattern.

Rich Dad Poor Dad Lessons Learned Notes Part 4 (final)

David — Thu, 26 Sep 2019 22:55:55 +0000

⦁ Intelligent people hire and are around more intelligent people then them.
⦁ Learn to sell, just because you have a masters in writing doesn't mean your books will be the best selling. To do that you also need to learn how to sell.
⦁ Learning a little about a lot helps you make better decisions about what is important and what is not.
⦁ When you want to earn more money take a long look at your life and look into getting a second skill. Education is more valuable in the long run.
⦁ Life is liking going to the gym, the most painful part is the decision to go.
⦁ Skills do not neccessarily transfer from industry to industry.
⦁ Rule of thumb for highly speccialized careers can be highly specialized then unionized, because unions protect highly specialized people.
⦁ Taking a course in sales and direct marketing can increase your value in any career, profession, or life goal acomplishments.
⦁ Being able to sell yourself/skills is the base of success.
⦁ The better you can handle communication and fear of rejection the better your life is.
⦁ To recieve money you have to give money.
⦁ When you want to become rich faster think like a texan, win big or lose big, but still keep going.
⦁ One of the greatest reasons for failure is lack of taking risks.
⦁ You can always turn a financial lose into a financial win.
⦁ Dont be buried by your failures, become inspired by them.
⦁ If you have little money and you want to be rich you have to be focused and make progress untill you can become balanced.
⦁ Building assets takes guts, patience, and passion.
⦁ Never say "I cant afford it" always ask "How can I afford it". This makes the human mind stronger.
⦁ Guilt is worse then greed, cause guilt robs the body of its soul.
⦁ Pay yourself first, and then pay everyone else. This forces you to work harder to make sure you have enough.
⦁ Forcing yourself to think about making money, builds strength in your mind about finances.
⦁ There's gold everywhere, most people are not trained to see it.
⦁ Don't listen to poor or frightened people, as they can always tell you why something wont work, but not everything they say is true.
⦁ Always listen to both sides of the debate, but make your decisions logically and without emotion.
⦁ Wise investors don't buy when things are popular, they get in early.
⦁ First learn the formula then put in the effort to use that formula. Knowledge without practice does nothing.
⦁ It's also now what you know that matters, but how fast you can learn something new.
⦁ Self discipline and fortitude is important to now let the world pull you around.
⦁ Don't dip into savings our liquidate stock to pay for consumar debt. Use the pressure to inspire you to make more money.
⦁ Savings are only used to create more money, not to pay bills.
⦁ Pay people well, cause real professionals service will make you money.
⦁ A broker is your eyes and ears in the market, they are there everyday so you don't have too.
⦁ There is a tremendous difference between a broker who just sells and and a broker who practices what they do. Always ask if they own large amounts of what ever they sell themselves.
⦁ Reward the people who are smater then you, a board of directors helps everyone make more.
⦁ Look at your assets extras after you get your money back.
⦁ Find heroes, look up to people who already have and do what you want. Learn from your heroes.
⦁ Teach and you shall recieve. If you want something you first need to give.
⦁ Stop doing what you're used to and look for something new, then take action.
⦁ The game of buying of selling is fun, just make offers cause someone may accept.
⦁ Profits are made in the buying not the selling.
⦁ Don't play it safe, play it smart.
⦁ If you know what you're doing investing is not risky, its just common sense.

Rich Dad Poor Dad Lessons Learned Notes Part 3

David — Mon, 23 Sep 2019 22:57:20 +0000

⦁ The majority of taxes aren't payed by the rich, they are paid by the poor and middle class
⦁ Taxes were made popular by the government telling the poor that the taxes were for the rich.
⦁ The government is respected and gets power based on its size. A rich man gets respect and power by paying less and keeping more income, aka not having tons of employees.
⦁ A corporation is merely a document in a clerks office that creates a body without a soul and protects the rich.
⦁ Average Americans today work 5-6 months just to cover their taxes.
⦁ The tax man is the biggest bully and will always take more if you let him.
⦁ It is expensive to not know the law, (I personally saved 1500$ after filing taxes by looking up a clause that I had missed and then fixed by amending my return.)
⦁ Corporations get taxed after they spend everything they can, basically money left over is what a corporation gets taxed on.
⦁ Rich use vehicles like corporations and trusts that protect their assets.
⦁ If you own any assets find out the benefits of setting up a corporation. (Personal corporations exists.)
⦁ Don't resist change, sometimes its the old ideas that are the biggest liability.
⦁ Never wait for the right opportunity, push to make the right opportunity happen
⦁ Knowledge is important, those who fail to recognize an oportunity lose.
⦁ If you don't have enough money for an oportunity, how can you still win from it, is financial intelligence.
⦁ You create your own luck.
⦁ Money is not real, money is what we agree it is, those who realize it can make more then those who don't.
⦁ Millions get made without money at all, because just by an agreement between two people, money can be transfered/made.(example buy sell stocks using broker.)
⦁ Humans are designed to learn by making mistakes, so while you should be carefull while getting rich, dont be afraid of losing or failure.
⦁ 2 types of investors the ones who buy a prepackage component and the ones who put things together to build an investment.
⦁ Huge wins come from those who can put investments together successfully.
⦁ Find opportunities that others missed builds your financial intelligence.
⦁ Learn how to raise money without a bank.
⦁ Its what you know, not what you buy.

Rich Dad Poor Dad Lessons Learned Notes Part 2

David — Mon, 23 Sep 2019 03:06:18 +0000

⦁ Money is an illusion, the government can make money by printing it, but rich people can make money by creating other things/jobs.
⦁ Being rich is not about how much money you make, its about how much money you keep and how many generations you keep it for.
⦁ To be rich you must be financially literate.
⦁ Accounting may be super boring but to be rich long term the lessons it teaches are important.
⦁ you must understand the difference between an asset and a liability.
⦁ The difference between an asset and a liability iis not words but what the numbers are telling you.
⦁ An increase in cash doen't make you rich if you just increase your spending.
⦁ A good mindset can be the one who always pushes to do things that others don't think possible.
⦁ Owning a home is a liability not an asset.
⦁ The greatest losses are those from missed oportunities.
⦁ Start an investment portfolio as early as possible.
⦁ You'll never be rich if your only source of income is your paycheck.
⦁ Wealth is how much money your money is making.
⦁ Always reinvest your excess cash into the assests.
⦁ Mind your own business. Basically when you work all your lives for a job, you're actually working for your boss, the company, the government, and the bank before you work for yourself.
⦁ Buy real assets not personal effects that lose value as soon as you get home.
⦁ Keep expenses low, reduce liabilities, and build a solid asset base.
⦁ Start collecting assets by using something you love. ( I love tech, so tech stocks will be more valuable to me then other things.)
⦁ Once a dollar goes into your asset columb it becomes your employee, and you should never let it out.
⦁ The rich buy luxuries last while the poor and middle class buy luxuries first.
⦁ Buying a luxury on credit often causes people to regret a luxury because the cost becomes a burden.

Rich Dad Poor Dad Chapter 1 Lesson Notes:

David — Sun, 22 Sep 2019 05:05:12 +0000

⦁ Learn as much about money as possible especially how to make money work for me.
⦁ Money is one form of power but financial education is more powerfull
⦁ The Rich don't work for money, they have money work for them, poor and middle class work for money.
⦁ Just because an idea fails doesn't mean you should give up. Basically never give up and allways think of new ways to make money work for you.
⦁ When you get fed up and angry because life is pushing you around, don't just get angry at your boss or coworkers or job, push back at life which is the one controlling everything.
⦁ When you blame someone else saying my boss or job is the problem you don't learn anything. You have to admit you're the problem in order to solve it.
⦁ To solve the problems life throws at you, you need to use your mind. think of new possibilities, options, ways to grow.
⦁ Every person has a week and needy part of their soul/person that can be bought. So to overcome life's troubles one must conquer that momentary glory.
⦁ Most peoples price come from fear and greed.
⦁ Don't fear not having money, think logically and overcome that life problem.
⦁ While working to becoming rich never fear losing money. All things can be brought back but when you fear loss you get stuck.
⦁ When stuck with fear for finding money, ask your self will a job be the solution to this fear in the long run?
⦁ Master the power of money instead of being afraid of it.
⦁ Self inflicted fear and ignorance keep people trapped and poor.
⦁ By not giving into emotions you give yourself time to think and solve problems more easily.
⦁ Never exploring your dreams because of fear is cruel.

LiveData Examples

David — Sat, 30 Mar 2019 08:54:52 +0000

So in Google Codelabs tutorial, Live observers are mentioned for passing data from the database to your activity. You are shown how to do 1 version of LiveData, which is to wrap a list in a LiveData<>, but what are some other methods and options out there? Well here I list a few examples, I have found through out the web.

First example

Is a simple Livedata that wraps around a list or item, it only changes when the database is changed in a separate manner.

Gets passed through the repository if you have it and then on to the view model:

then the viewmodel gets initialized in your activity class so you can create the observer and pass its data to your data holder.

Second Example

Passing in parameters to the LiveData

modify the dao

and at the ViewModel you need to use a second LiveData known as MutableLiveData.
This MutableLiveData will be used for passing in a query term to the original LiveData from the activity.

The only change this causes in the activity code is an extra call to set the search_term

Third Example

Passing in LiveData to a PagedList. Uses android architecture Room to create a Datasource.factory method from sql.
This method is a great way to populate PagedLists, I only learned a bit about it because I mistook it for a pageAdapter when I was first learning Android.

First modify your DAO to use a datasource.

In the Viewmodel class you set up your paged list to interact with the LiveData.

Finally you set an observer and pass in your factory data to an adapter from the pagedList, this is basically the same as example 1s.

While example 1 and 2 will generally work as is, example 3 tends to be harder to implement depending on your data , but for now this is the simplest example I could write up. without any extras that are usually associated with the PagedList.

My First Published App (part 2)

David — Sat, 30 Mar 2019 07:01:19 +0000

about

For those reading this and not having read part 1, this is just a compilation of my personal experiences programming and publishing my first app. While eventually I would like to get good enough at writing to write tutorials, for now I am just practicing using my recent experiences. Thank you all for your time.

Coding

My app OWL Flashcards level 1 en - cn uses a total of 6 screens, in this part I will be going over some of the screens and explaining how I built it and some improvements I made along the way.

Title Screen

The title screen is composed of text views, image views, and a button for going to the next screen. They are all inside a linear layout(vertical or horizontal depending on the orientation) and that linear layout is wrapped in a scroll view inside of a constraint view.

I initially set up the scroll view to try and work around creating multiple screen layouts for different orientations and dimensions... it did not work. I eventually went and created a separate layout for every needed dimension, but as I was writing this, noticed I forgot to clean up the old scroll views... oops.

The title screen is not the parent activity to any other screens, because I only wanted it to appear briefly while the user enters the app, this screen was designed to introduce basic info about the app when ever it was first started and after that it was not necessary. The only significant programming I did on the title screen was that the very first time the app was started a pop up custom alert and toast message would be displayed.

The custom alert dialog was for entering a users name and saving it into the default shared preferences, so that for every following time onCreate() is called for the activity a welcome back, 'display name' custom toast was shown.

The alert init code:
AlertDialog.Builder alert = new AlertDialog.Builder(this);
final EditText edittext = new EditText(this);
alert.setMessage(R.string.set_display_name_alert_message);
alert.setTitle(R.string.welcome_to_owl_flash_cards_alert_title);
edittext.setText(mPreferences.getString(SettingsActivity.KEY_PREF_EDIT_USER_NAME, ""));
alert.setView(edittext);

It creates an edit text and if a user name was already in the default shared preferences, it displays that username so that it can be overwritten. After that it sets only the positive alert button.

alert.setPositiveButton(R.string.alert_dialog_ok_button, new DialogInterface.OnClickListener()

inside the positive alert it saves the new user name and sets the get_user_name preferences to false so that the alert doesn't pop up every time.

This allowed me all the data I would need to populate my greeting message for returning users.

Toasts are interesting, cause googles guidelines usually say to remove toasts before publishing, so I tried to find an alternative like snackbar for my popup message, but it's color library had trouble with cardviews color library, and I decided I wanted cardviews color library, so I couldn't use snack bar.

The solution was a simple hack where you generate the toast message, but change its layout. To do this you create an xml layout, inflate it with the layout and a view group.

View layout = layoutInflater.inflate(R.layout.welcome_custom_toast_message, (ViewGroup) findViewById(R.id.custom_toast_welcome_message));

then you can create a new toast, set the gravity(optional), the duration, and pass in your layout.
toast.layout(layout)
and show it. it is a remarkably easy and simple fix, but I still have to look into why toast messages are generally frowned upon in published apps.

Main Screen/Menu Screen

The menu screen consists of 10 buttons, (9 of which lead to the same fragment activity but with different intent data for populating it, and the other 1 leads to its own activity which is essentially a long screen of text.) It also has an options menu to go to the settings activity or the search activity. The main menu is also used as the parent activity for nearly all screens in my app.

The 9 major buttons were different categories of flash cards for easier reading, the way I handled this was to pass in a public static final int into the intent extras so that when the new activity received the intent it populated itself using the correct data. I use to have more then one activity handling each button, but after taking my certification test through google, I realized I could simplify the app greatly by using Android ViewModel correctly.

The Menu screen has two interesting code segments.
First I wanted my buttons to be perfect squares, so that when they scrolled up and down the screen they were nice and uniform. To do this I had to create a ViewTreeObserver object based off of one of my buttons, then I set a GlobalLayoutListener for it. Inside the GlobalLayoutListener I was able to use the buttons getMeasuredWidth() to get the final width and pass it into my other buttons as the height, so they would become square.

ex:
ViewTreeObserver buttonSizeObserver = mAnimalButton.getViewTreeObserver();
buttonSizeObserver.addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
@Override
public void onGlobalLayout() {
mAnimalButton.getViewTreeObserver().removeOnGlobalLayoutListener(this);
int width = mAnimalButton.getMeasuredWidth();
mAnimalButton.setHeight(width);

The whole reasoning for it, is when you are in oncreate the button widths are sometimes not set, so if you call the getMeasuredWidth() without the observer the width could be null, causing your buttons to dissapear.

The second interesting thing I had to do in this activity, was to init my database. I discovered through testing that the first time the app was installed if you went straight to the flashcard page they would be blank and you would have to either press up or back to go back to the menu and then you could try again. I assumed no user would want to have to go back just to use the app the first time and so the solution was to init the database early so that any prepopulated data was ready for use when the user entered the next screen.

Flashcard Screen

So this screen consisted of 2 text view elements, 1 image view, and 1 image button element. The text views got populated with either the current English or Chinese word and its pronunciation spelling. The image view was one of two images based on what language the text view were in, and the image button was a play button to play the sound of the word from the text view.

To make each card feel like a flash card I had to set an onClickListener() to my primary Viewgroup, this allowed me to change the text, and image views/buttons based on a user click/tap. I used a boolean for this to decide which language to use.

To make it so there was more then 1 card at a time I used a viewPager which was populated in the activity class. The view pager initiated my fragments by calling a static function named newInstance for the fragment, which then in turn called each ones own default constructor and returned the fragment. The static function also took in data passed in from the pager and placed it into a bundle so that the fragments onCreateActivity could parse it.

The Fragments bundle extras, caused me confusion at first because I created a database with multiple tables and tried passing in a unique table each time, this method forced me to have multiple fragments and pageadapters. when I simplified my database to 1 table but with a row for categories I was able to reduce a lot of code redundancy for creating the fragments.

I discovered while building this page that ViewObservers are fun and have multiple options for storing and recalling data in a database. While tutorials might be lacking a bit on them, a few android doc codes have enough details to get many people started.

Search Page

Android has a search widget and documentation to try and use it, But I wanted to try my hand at a custom view. So I simply created a layout for a button and edit text field, and attempted to put it into a custom view, got annoyed and put it directly in the search page instead. I've learned since then how to fix my problem I had with the custom view, but that is for a later blog post.

The search page used an interesting technique with LiveObservers interacting with the viewmodel and database.

It consisted of initializing a live observer, but also setting a second MutableLiveObserver with the search term. It did this so that the viewmodel class could keep the first LiveObserver as private, and not have to the user interacting with it directly, basically simplifying its job so that it could handle data changes more efficiently.

ex: search Activity
mViewModel = ViewModelProviders.of(this).get(CardViewModel.class);
final Observer> cardObserver = new Observer>() {
@Override
public void onChanged(@Nullable List cards) {}
mViewModel.setSearchTerm(mLastSearchTerm);

View Model Class

public LiveData> mSearchedCard =
Transformations.switchMap(mSearchTerm, searchTerm -> {
return mRepository.findCard(searchTerm);
});
private MutableLiveData mSearchTerm = new MutableLiveData<>();

public void setSearchTerm(String term){
mSearchTerm.setValue(term);
}

The reason for the LiveObserver for the search activity was so that the user could search more then once, and that I wouldn't have to use loaders and async tasks to retrieve new results or to store the previous results.

The concludes the major interesting points for coding my First Published App, Later I might add in a part 3 about the publishing side through google play.

My First Published App (part 1)

David — Thu, 28 Mar 2019 02:20:46 +0000

Intro

Hello Everyone,
I just finished publishing my first app into Google Play. I decided to write this to commemorate the experience and to give a few tips on building and publishing.

This post should not be followed to the 't'. I am only recently certified as an Android App Developer and there are many ways to build your own professional apps. This post is intended for those who want to go through the building and publication process, and feel they want to know others experience to help them get past the nervousness throughout publishing.

About

OWL Flash Cards Level 1 en-cn. Code Repo, App

Created using Android Studio version 3.3.
Requires a minimum SDK level of 19.
Compiled for SDK level 28.

Additional Dependencies: Firebase, Support, Arch.Persistence.Room, Arch.Lifecycle, and Expresso for testing.

Starting a New Project

Creating the Idea/concept.

Well first I am terrible at speaking Chinese, but I married a girl from China. So after being married for a while I attempted to learn Chinese and I basically hated the way most programs taught you. I wanted a quick way to learn a word or two when I had free time, and the best way to do this seemed to be flashcards.

For creating your own app idea the best method is usually just, what do you want and then expanding it outwards to help other people too. This can make it helpful for similar minded people to be easily attracted to your app idea.

Creating a look for the Idea.

Many people have heard of flashcards and probably used them, but how do you design an app to appear like them?

First off you can try reading designers tips and tricks for making beautiful card animations, but that will usually lead to a road block if you do it too early on. The best method I have found is to start smaller:

Create a single app page and design its layout.
- this can be done by drawing on paper or using an editor.
- start by placing required items first "title bars, nav bars, etc...
- don't pick colors too early, styling the background and elements may be fun but doing it too early leads to messy code and lots of cleaning later.
- Fill in the rest but don't forget to leave spaces for your own logos and titles.
- Lorem ipsum is a great way to put filler text, until you've organized your layout more. *remember to draw buttons for apps with more then 1 screen, or look into other options like the navigation drawer.
Reference other apps, does the page you created look like a home page, a menu, the main content, etc...
- If not a normally used design, think of ways you can either improve your own design by referencing others or go try and explain how to use your design to a friend. If you can't explain it in person there is almost now way users will understand it by only seeing it.
- You don't need to look exactly alike other apps, but people tend to do sloppy designs unless designing is their profession. So use other apps as reference when possible.
- Doing all this helps build validation that you are creating a professional app.
Create a story board for apps with more then 1 page.
- This way all your designs and pages are in a line so when you jump to functionality you remember who connects to who.

I personally redrew designs and storyboards for about a week straight until I discovered that for now I just needed the most simple of layouts.

Android Studio first time build

So Android studio gives you a few basic templates, now if you don't need any extra templates you can use the empty activity layout. But remember to not just jump to this as a default, look at what you did when designing your app, did you push all your buttons for changing screens to a nav drawer, well if so android has a layout already for you.

Remember to look at what's available, so you don't have to recreate the wheel later.

Building the app layout

Finally we can start coding. This app's prep work took me quite a bit of time, but it was super worth it to be able to start coding and see the layouts I made popup on a phone screen.

Now for the home screen and menu screen, it was quite simple at first. I needed only a LinearLayout to hold my views which consisted of Textviews, ImageViews, and Buttons, But that was a wrong assumption on my part.

Linear layouts are great but they are only one direction, so if you want two items in a row you have to add in another layout group. If you add in a second Linear layout to hold the two items you also need to worry about layout weights. Layout weights are great because they can help organize your content for multiple screen dimensions but can cause performance issues when nested inside of each other. This is caused by the computer having to call onmeasure and ondraw multiple times in order to correctly process the dimensions of each item, which slows down all other resources, usually annoying the user greatly.

So what did I do then to maintain flexibility for different screen dimensions?
For the Title Screen I used a constraint layout as the parent and placed a scrollview inside. The scrollview wrapped around my linear layout allowing my app to go past the boundaries of the phone... and yes I know this is wrong for a title screen, because if parts of your title, or following content goes off bounds, what user will think, 'oh i can just scroll to it, its ok'. None that's who. But when I was testing on multiple device screen I allowed this early mistake, so that I didn't have to build a horizontal orientation at the moment.

I did later go and build horizontal layouts for my pages, but at first I focused on functionality, and that's ok. If you do decide to focus this way, make sure you implement a //TODO reminder so that you don't forget about something later.

Fragment layout building

Fragment layouts are included into a pre-existing layout, so remember your view hierarchy and avoid nested weights, forgetting the parent already had weights, can cause serious performance issues.

My app currently uses 2 fragments, one for the settings preference fragment and one for the flashcards themselves. Building the layout was semi straightforward, except that it took me a while to figure out, how to make the card flip over and show the translated side. But more on that in Part 2.