ismail-s / jtime Goto Github PK

Do #33 first.

Look into http://fbredex.com/

Add getInstance method to RestClient class. To slightly improve performance so we don't keep creating a new instance.

A MockContext should be used as a placeholder for a real Context and a real Context added during application initialisation.

• All strings, whether in xml files or kt files, should be in strings.xml, unless there is a good reason for them not to be there
• The strings themselves need to be reviewed to maybe rephrase some of them.
• Some messages need to be removed, as they were more there for debugging. Eg the toast saying that we are not currently logged in.

If the salaah time is the same as the currently persisted one, don't bother saving it.

See http://kovenant.komponents.nl/ for more info on the promises library.

I should have been doing this as I went along, but it was quicker to leave it until now.

Might be worth using in the future. See http://android-developers.blogspot.co.uk/2015/05/android-design-support-library.html

This may just be as an nginx config...

This is only for users creating accounts using the built-in email/password method. But this would then also be used for password resets.

1. Pad the map so the submit button doesn't obscure map buttons
2. Add a label floating at the top of the map that says eg "Long click on map to select location". Or maybe this should be a long toast, but long toasts can be loong. Also, with toasts, the message isn't persistent.

Create a starter framework that I can then flesh out into a fully featured app

• don't allow editing magrib times in android app
• don't allow masjid times with type "m" in the rest API salaahTimes table

Atm, I think we should just not display it at all, or at least leave it as blank and not allow setting it. As in future, it should be computed, as it can.

There are various ways this can be done. The main 2 ways are to either do the computation server-side or client-side. Since all other times are obtained from the server, it probably would be easier to computer magrib times there.

https://www.npmjs.com/package/suncalc can be used to do this computation. There are not many rest endpoints that return salaah times, so the code for those few endpoints can be altered as required.

The rest endpoints should send sunset time under the salaah code "m" (for magrib). On the client side, there should be a setting to set how many minutes after sunset magrib is. By default, this should be 5. If making this configurable is too much work for this issue, then that can be spun off into a separate issue that can be dealt with later.

• https://www.npmjs.com/package/cache-manager
• finish modifying rest endpoints
• Update Android app to display magrib times
  • RestClient needs to handle magrib times correctly
  • HomeFragment needs to display magrib times, maybe collapsing them where they are all the same
  • MasjidFragment needs to display magrib times

• Create rest endpoint that tries to find an existing time. If so, it modifies that, otherwise it creates a new time.
• Create method in RestClient that calls this new rest endpoint
• Handle all button clicks
• Limit no. of chars allowed in textbox & which chars are allowed (probs use android:digits & android:maxLength)
• Make sure everything is appropriately sized
• Fix issues with buttons being enabled whilst switching days
• Keep keyboard open at all times, except when opening navigation drawer
• Hide edit button unless logged in

This is a complicated one. There are a few different ways of laying out this fragment and the best one needs to be used to allow for fast data entry, without repeating oneself.

My current idea is to edit one time for one day at a time, with arrow key like buttons to switch to other days/times and to copy the current entry to the next/previous day.

But the important part is to get something working first, even if eg how it updates the server is not optimal. Then the functionality can later be improved.

An attempt at a pictorial representation of how the navigation should work (arrow points to child screens, children navigate backwards to parent):

home -> nearbyMasjids
home -> allMasjids
home -> addMasjid
home -> help

allMasjids -> masjid
masjid -> changeSalaahTimes

https://docs.strongloop.com/display/public/LB/Operation+hooks

Dealing with duplicate masjid times is to be covered in #26.

The method needs to check the sub field. I know what this means...

When the Rest server returns errors, we should display these errors to the end user. In future, this could be changed so that the Rest server returns error codes too, and we use those to display a localised string, but atm that would be more complexity.

• Sign in
• Sign out
• Persist tokens and wipe when signing out
• Check on startup if have been logged out on server-if so, wipe persisted token, update ui

Be able to sign in, sign out and store the token in a persistent fashion. So that when the app is opened we can check to see if they are still logged in rather than logging in each time.

Atm, there are a whole bunch of kotlin files in the activity folder. Things need to be sorted out much better.

The following endpoints should be public

1. GET /masjid
2. GET /salaahtime

and the following should be only for logged in users

1. PUT/POST /masjid
2. PUT/POST /salaahtime

and the following should be only for admin

1. DELETE all endpoints

See https://circleci.com/docs/android/

Use the RestContract thing. I know what this means..

Columns:

• Id
• up/down vote
• voterId
• timeId
• createdAt

By having this as a table, it means that we can keep track of who voted for what, when. Downside is that it is one extra SQL query to count the rows, but meh, that can be optimised if it becomes an issue.

I have already tried to do this and have encountered the error:

Warning:com.strongloop.android.remoting.adapters.RestAdapter$RestHttpClient: can't find referenced method 'com.loopj.android.http.RequestHandle get(android.content.Context,java.lang.String,org.apache.http.Header[],com.loopj.android.http.RequestParams,com.loopj.android.http.ResponseHandlerInterface)' in program class com.strongloop.android.remoting.adapters.RestAdapter$RestHttpClient

along with similar errors.

Removing the loopback android sdk and just using AsyncHttpClient directly may be better, along with removing a dep, which is often a good thing.

Sounds obvious, but I keep forgetting it
Basically, a fab icon on the list of masjids redirecting to a fragment with textboxes and a submit button. Nothing fancy, just name and maybe location. After go live, things can be made more fancy.

See http://tools.android.com/tech-docs/new-build-system/tips#TOC-Improving-Build-Server-performance. Apparently, it might speed up the builds.

I'm thinking of using https://github.com/mikepenz/MaterialDrawer.

Seeing as I am using Fuel for any new networking I am doing, it would make sense to make all code using loopback sdk use Fuel instead.

In other words, go through https://docs.strongloop.com/display/public/LB/Security+considerations and make sure all that should be done is done.

When a masjid is created, we should use the [Google maps web api](The Google Maps Geocoding API  |  Google Maps Geocoding API  |  Google Developers) to get an address & store that on the masjid object. When returning a list of masjids, this can then be returned and used to display the address in the app.

Atm, only en_us addresses should be used. Handling other formats can be dealt with in a later issue.

I should probably this node module to keep the code nice and simple.

Use cardviews with more information about each Masjid. http://developer.android.com/training/material/lists-cards.html#RecyclerView

Things that can be shown for each Masjid:

• Name
• Location as human readable string

See https://kotlinlang.org/docs/reference/properties.html#late-initialized-properties

Populated by whatever user was logged in and created that row

Return all the times for that day, and all the votes.

In lots of places with loopback, descriptions can be added.

What would be on the sidebar would be fajr, Zohar, ...

Clicking on one would show a list of those times for the nearest masjids, and any favourites masjids (future work). Basically an alternative way of looking at the data.

The idea is that this enables quick answering of the question "which Masjid shall I go to, which has the soonest time".

The simplest way is to say that KitKat is the oldest supported OS version. But there are still people using older devices.

Use passport.js. Sign in with Google will be the main/only way of signing in at first. Later on, I can add other stuff.

Note that loopback comes with some builtin user registration/login/logout functionality. Passport.js is then used to add on to this more login methods.

Basically, cache the data that the rest API returns. Then, always show the cached data first, whilst doing a network request in the background. To speed things up and make the app work offline.

An action bar would be where a button to open the navbar could be. And it would display the title of whatever fragment is being displayed.

https://developer.android.com/reference/android/support/v7/widget/Toolbar.html

• Title
• Login status
• Map position when adding masjid
• State when changing salaah times

Atm I haven't paid attention to screen orientation changes at all. So rotating the phone has essentially reset whatever is being displayed. Eg the logged in check happens each time the orientation is changed.

atm It is stored in loopback in-memory db

Things like type of salaah need to be validated.

This is for the sake of keeping things tidy, as well as being able to document the endpoint, and other advantages of using loopback.

This will also require updating the url in the Android app.

See how the website looks as that is designed to be responsive.