julianharty / app-store-reviews-app Goto Github PK

A profile of reviews may help us to test this application more effectively. There are many ways we could profile reviews.

Activity:
Please suggest possible profiles and the reason you consider the profile relevant from a testing perspective.

Activity:
We can review source code ourselves. With some practice and experience we may well detect possible bugs. If so, how might we test these bugs?

The IDE includes tips for potential flaws and improvements. If you have Android Studio and the source code for this app, review various tips and compare these with the potential bugs you have observed. How might we test these bugs?

Particularly for testing, it'd be useful to be able to purge the database. Currently there's only one table - the one that contains the reviews. Eventually I'll add additional tables so I/we will need to remember what purging means from a user's perspective and whether to provide facilities to purge individual tables, all tables, and whether there will be relationships between tables that matter and could be affected by purging some or all the data.

Thankfully, for now it's fairly simple to implement and about time to implement this capability ready for testing duplicate handling.

Add Mobile Analytics library to the app. First decide on the data I'd like to capture when the app is being used. Then decide how to represent these in API calls & implement them. Test :)

There are two ways of adding a review to the database. I've been updating one but not the other. I've now added sufficient functionality that I've introduced a flaw in the method that's been languishing. It's time for me to either add equivalent functionality or merge the 2 methods.

The SQL create statement has some bugs in it's data type definition.

The CSV files of reviews from Google Play Developer Console are currently in UTF-16 encoding. However the reviews don't have to be in UTF-16 encoding. Also other CSV files may be in other encodings e.g. ASCII, UTF-8. It'd be good to correctly process these files, if only to improve the message provided to the user. Currently my test file which has perfectly legible headings in English is interpreted as Chinese which ain't very user friendly or accurate.

It's time to consider adding more tracking information in the app. I'd like to track which files were imported, when, and the results. This will be useful to understand how the app's being used and may also help users to know more about what they've done and help them decide which file(s) to import next.

I'll need to learn more about Intent.ACTION_OPEN_DOCUMENT and how to obtain the filename (including the path) as well as other data e.g. the filesize, last modified timestamp (if available), etc.

I've added a very basic welcome page to the app. It's currently text-based and not attractively formatted or actionable. I'd like to make both happen, but want to focus on the core functionality first. This issue is to help me remember to make this happen at some point.

Google Analytics can track various types of information:

• events: things that happen
• goals: when you want users to achieve a goal
• usage: how users navigate through the app
• timing: how long things take
• errors: when things go wrong, such as exceptions reported by the app when it's running
• installs: how users obtained your app

This exercise is for us to decide what to track in the app we're working with.

The current parsing fails to distinguish between commas separating values and commas in the value e.g. in a quoted string "this, not that". Here's the current code:

String[] nextRow() throws IOException {
    String line = reader.readLine();
    return null == line ? null : line.split(",");
}

I need to implement a more discerning parser. Time to do so about now :)

BTW: it might also be worth adding some robustness checks against the contents being read to detect and cope with malformed CSV files. And finally for this bug/enhancement - make the program robust so it doesn't crash when problems happen (currently the app quits - not what I or the user wants).

I've added a summary of the number of files imported in the Statistics view (see #14).

I'd like to provide details of each file that's been imported. To do so, the GUI will need to be revamped somewhat. Rather than overload issue 14 I'd prefer to close it and open this enhancement. Provisionally we may be able to use the same presentation in both the statistics view and when importing files. Something to consider, not to commit to at this stage.

After adding the Files imported count to the Show Statistics view I realised that when the user deletes all the review history the app doesn't delete the file import history. While this isn't mandatory, perhaps it'd be more consistent to wipe both histories clean - especially as otherwise if/when I add logic to see if a file's been imported previously the app may erroneously treat the reviews as being in the database when they're no longer stored.

Something to consider when revising the app.

I installed my app on an oldish HTC Desire 501 running Android KitKat. I noticed the Google Analytics messages weren't being sent. The reason reported in the Android log is that the Google Play services were too old. Google Analytics now relies on the GMS service. Sadly the adb log wrapped before I saved a copy of the messages. I'll try to get a copy when I next install the app on a disused device.

I've tagged this as a question as it isn't a bug I can fix.

Currently the app blindly imports contents, even if it's already imported them before. I don't think it's useful to have duplicates of contents, so let's find a way to firstly detect duplicate content and then leave the existing content in-situ if we detect a duplicate is being ingested.

Of course, it'll be helpful to communicate dups were found. Quite how is to be determined as the most appropriate form of comms may depend on the number of dups found e.g. 1 is fairly practical to show in the GUI, many ain't.

The data store setup could use being refactored to support using ANSI SQL for the data type definition and different storage approaches.

Currently the code will try to import any CSV file the user selects. Grocery lists, ping-pong scores, etc. are all equally welcome, but not equally useful for this app. Let's add some content detection and find ways to politely communicate when what we find isn't what we can cope with.

I've discovered that the ScreenName needs to be set explicitly otherwise events for other activities have the most recent ScreenName set for them i.e. it persists in the Application level Object.

This led to misleading reports and me being confused until I looked at the Android log (with debug level tracing enabled for Google Analytics).

Users may like to see how many reviews they've got and various statistics on how many they've processed. This would be useful in the GUI and potentially as analytical data reported back for testing and development purposes.

For now, let's start with the count of records in the local database.

Google documents the collection protocol. Many of these (but possibly not all) are used by the Google Analytics client when transmitting events.
https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters

Review and consider what data we could usefully collect to help us better understand how our software is being used.

This topic is something ingrained into my memory. I know it'll need to be done. This is to let others know that I know the current GUI is poor and would benefit from significant improvements. My current focus is to implement the essential functionality sufficiently so the app can be used for testing and research.

The app currently has a crude import capability. If it fails for whatever reason, the user isn't notified. And while I think about it, we don't communicate when a file is loaded successfully. Let's find a way to communicate the results of trying to import a file.