All the good work to make sure that `getActivity()` actually returned
a proper context, obtaining a final reference to that known good activity
object, and then using that in the background thread is thrown away.
The reason was because the `translateCategories` method would go and
call `getActivity()` all over again. This changes the `translateCategories`
helper function so that it asks for a `Context`. This way, a known
good `Context` can be passed in, rather than having to perform a check
to see if `getActivity()` is good again.
Code Style : Changed variable names to be consistent with other variable names
variable names are inconsistent in other files as well. At some places it is `mVariableName` and in some places it is `variableName`.
suggestion : rename all public variables to `publicVaraible` and all private variables to `mPrivateVariable` ?
we can use http://udacity.github.io/android-nanodegree-guidelines/index.html
See merge request !225
Translators:
Adrià García-Alzórriz Catalan
Adrià García-Alzórriz Spanish
Benedikt Volkmer German
Irvan Kurniawan Indonesian
Licaon Kter Romanian
Marcelo Santana Portuguese (Brazil)
Massimiliano Caniparoli Italian
Mladen Pejaković Serbian
Mohamad Hasan Al Banna Indonesian
naofum Japanese
Pander Dutch
Phạm Nguyễn Hoàng Vietnamese
riotism Chinese (Hong Kong)
Tobias Bannert German
Verdulo Esperanto
Verdulo Polish
Previously, it was not explicit that the `onCreate` happened to be invoked
in the UI thread. Now it is, due to passing `new Handler(Looper.getMainLooper())`.
Also, the categories are now loaded in a background task, and then the UI is
updated on the UI thread.
Translators:
ageru French
Danial Behzadi Persian
enolp Asturian
ezjerry liao Chinese (Taiwan)
Fr Translation French
Hsiu-Ming Chang Chinese (Taiwan)
Jonatan Swedish
relan Russian
riotism Chinese (Hong Kong)
Translators:
Adrià García-Alzórriz Catalan
Adrià García-Alzórriz Spanish
Ajeje Brazorf Sardinian
Alberto Moshpirit Spanish
Alex Kalles Greek
jetamkadlec Czech
Ldm Public French
Licaon Kter Romanian
Mladen Pejaković Serbian
naofum Japanese
Olexandr Nesterenko Ukrainian
Verdulo Esperanto
Verdulo Polish
Previously, they were registered, then forgotten. This means that each time
the start swap view was run, another receiver was registered. As a result,
they were being invoked multiple times.
It doesn't appear that this had any specific side effects which were terrible,
but they definitely have the potential to going forward.
Note that because we are not using `Fragments` with their convoluted, but at
least well documented API, I'm not 100% certain that I've unregistered the
receivers at the right location.
Previously, something like this would happen:
* Swap service is cancelled
* WiFi swap is asked to stop
* Event is broadcast when done
* UI listens to this event
* Upon receiving the event, it updates the UI
* Updating the UI triggers an event, causing the process to happen again
An alternative solution to this would have been for the UI to stop listening
to listeners before WiFi swap is shut down, but that is then only specific
to the case when the swap view is being destroyed/removed. This could also
happen in other situations however, such as when the swap service times out.
When the view is detached, then the listeners will be unregistered.
This will also help in the future so that they can be temporarily
unregistered when manually changing the state of the switches.
Thread runs at normal priority by default. AsyncTasks are integrated into
Android for handling things running in the background while keeping the UI
responsive.
This reverts most of commit 828cc272ee5235f868104b009349cc7e835e144f.
