Maybe by using a lighter background colour for those particular list items.
Should also add an option to hide sticky topics.

Can already read PMs and reply to existing threads - just need to figure out a good way to handle this

Some errors are unavoidable (eg 500 internal server errors causing null String input to Jsoup.parse() method) - these can be handled by notifying user and repeating the network request.

eg return null from scraper if string input is null, check for null in onLoadFinished , display notification and retry request after certain amount of time. Need to think of sensible way to handle retries

Basic implementation: 528e519

Todo:

• Disk caching daf4b1b
• Fix resizing 54237a4 2bbcafe db0ef21

(ie. not just message list/inbox threads)

See: http://stackoverflow.com/questions/16736856/what-should-be-in-my-gitignore-for-an-android-studio-project

Should replace board list with a bookmark manager which allows user to choose default bookmark to load on startup (scraped from ETI) and create/remove new custom bookmarks. BookmarkManager should only load after login if user hasn't already chosen a default bookmark.

Something similar to the way that Google Chrome handles page refreshes. Might be possible to implement this using OnSwipeListener class

If user presses back button while EditText is focused then contents should be erased. If no contents, then call its super() method

E/AndroidRuntime: FATAL EXCEPTION: main
                  Process: com.sonicmax.etiapp, PID: 8222
                  android.view.WindowManager$BadTokenException: Unable to add window -- token android.view.ViewRootImpl$W@1a30dd2 is not valid; is your activity running?
                      at android.view.ViewRootImpl.setView(ViewRootImpl.java:678)
                      at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:342)
                      at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:93)
                      at android.widget.PopupWindow.invokePopup(PopupWindow.java:1380)
                      at android.widget.PopupWindow.showAtLocation(PopupWindow.java:1156)
                      at android.widget.PopupWindow.showAtLocation(PopupWindow.java:1119)
                      at android.widget.Editor$PinnedPopupWindow.updatePosition(Editor.java:3084)
                      at android.widget.Editor$PinnedPopupWindow.show(Editor.java:3040)
                      at android.widget.Editor$SuggestionsPopupWindow.show(Editor.java:3484)
                      at android.widget.Editor.replace(Editor.java:359)
                      at android.widget.Editor$3.run(Editor.java:2129)
                      at android.os.Handler.handleCallback(Handler.java:751)
                      at android.os.Handler.dispatchMessage(Handler.java:95)
                      at android.os.Looper.loop(Looper.java:154)
                      at android.app.ActivityThread.main(ActivityThread.java:6077)
                      at java.lang.reflect.Method.invoke(Native Method)
                      at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
                      at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)

Skimming through Google results seems to suggest this can be caused by trying to show a dialog while the activity is being destroyed - seems unlikely to be the case here

Would probably use the topic list fragment to display inbox threads, and then use a new fragment to display the threads themselves. Would look good with an instant message style UI where the messages are displayed in speech bubbles, sender/recipient usernames and avatars are aligned to left/right side of screen, etc

They are practically identical and it would take little work to combine the two classes.

Ideally the scraping logic would be separated out into its own class, and the rest of the code could be moved to PostMessageFragment/PostTopicFragment respectively. This would enable us to use AsyncTaskLoader to handle the GET/POST requests instead of AsyncTask.

At the moment the app scrapes bookmarks from home.php each time you log in - this is slow for the user, and not really necessary. Instead, we should store the bookmarks after first load (possibly in a SQLite db) and display bookmarks from cache on consequent loads. To keep bookmarks up-to-date, we should check home.php for changes in background & append/remove bookmarks if necessary.

Currently it attempts to load them all at once and updates UI whenever the request finishes - would be better to load them in order.

Set it to AlertDialog.THEME_HOLE_DARK for now, but this is deprecated and we should find a more permanent solution.

Otherwise app will be unusable while tag server is broken. Shouldn't have to change much code to make this work

• Need to provide orientation information to user
• User should be able to navigate easily to any given page in a topic list/message list

The endpoint: http://boards.endoftheinter.net/ajax.php?r=1&t=topicnumber

Change r parameter to 2 to unstar topics. We can find out whether a topic is starred or not from the topic's HTML.

Previously not possible (as you can't use iphone site session cookies to access wiki), but I created an API for it (https://github.com/sonicmax/dramallama) which should work fine.

Instead of loading bookmarks, we can jump straight to topic list (as bookmarks can easily be viewed in navigation drawer). For now I will just jump to the first saved bookmark, but in future this should be customisable via options menu

Can't long click on views containing ClickableSpans

Should display some kind of notification (Snackbar?) if the phone is not connected to internet and prevent the app from making web requests. Otherwise it crashes

E/MessageListAdapter: Error parsing date for getView method
                      java.text.ParseException: Unparseable date: ")" (at offset 0)
                          at java.text.DateFormat.parse(DateFormat.java:626)
                          at com.sonicmax.etiapp.adapters.MessageListAdapter.getFuzzyTimestamp(MessageListAdapter.java:162)
                          at com.sonicmax.etiapp.adapters.MessageListAdapter.getView(MessageListAdapter.java:148)

I think this is caused by existence of "(Formerly known as: old username)" in message-top elements, need to add a separate check for them. Probably need to check for money bags too

Need to use something like this: https://www.whatismyip.com/api-documentation/

Presumably they just need to be URL encoded.

CardViews are neat and cool and we should use them

Would probably be a good idea to keep the SpannableStringBuilders generated by MessageBuilder/SupportMessageBuilder in an LruCache object. (Not sure if that would cause problems with async loading of images)

Also the message layouts should be generated in a background thread - leads to a weird experience on devices with poor performance

eg ignorator, highlighting, choosing whether to render images or not, app startup behaviour, etc

For example, this <b> element:

<b><spoiler>lol</spoiler></b>

would render the inner HTML as it appears in text form, rather than as spoiler-tagged content. We need to iterate over the child nodes of these types of elements to make sure that content is rendered correctly

Eventually this will be customisable, but for now we should copy some of ETI's popular themes and include a dark theme for amoled screens

Need to test Scraper classes, LivelinksHandler, and probably other stuff

The current implementation seems to block the UI thread with large numbers of images being loaded, and it's kind of slow

We can use interfaces to communicate back with fragments. See 48447ea for example

Enable user to post messages/replies to messages without starting a new activity. We can restart loader to view new post, or let LivelinksHandler deal with it (once it has been implemented)

Need to make sure that the token value remains the same from message list to postmsg.php (if users don't use quickpost/quickreply feature).

Works fine in emulator (at any API level) and on newer phones, but gives a response code of -1 on Samsung Galaxy Fame S6810.

-1 is the default value for response code, so it seems as if something is interupting HTTPSUrlConnection and preventing it from getting a response. Doesn't throw any uncaught exceptions. Needs further testing.

Should also note that this wasn't a problem while app was using AsyncTasks to handle web requests (instead of AsyncTaskLoaders)

AsyncTaskLoaders make sense in most cases (and are already used for majority of requests). Not sure that AsyncTaskLoaders are appropriate for making POST requests, but we need to use something that won't break on screen orientation change/etc.

• PostMessageHandler/PostTopicHandler (#6)
• AccountManager uses AsyncTask for the logout request

Should modify back button behaviour so that pressing it twice quits the app, instead of going back to LoginActivity (which is pointless if user has already logged in & we have a working cookie). User should have to explicitly choose to logout in order to get back to LoginActivity.

We need to save the adapter data in onSaveInstanceState() so it can be used to repopulate the adapter in onCreate() if the fragment has been destroyed/etc (for example, after a screen orientation change).

Example log:

V/WebRequest: headerFields: {null=[], =[0], X-Android-Received-Millis=[1486564615173], X-Android-Sent-Millis=[1486564615173]}

V/WebRequest: responseCode: -1

The response headers are fine with other types of POST but for some reason the postmsg.php response is totally messed up. Need to test in different versions of Android. Might be worth looking into using asyncpost.php endpoint instead of postmsg.php

We can work around the error by just not showing "Message posted"/"Post failed" snackbars after quickposting if -1 response is detected, but ideally we should fix this.

(specific performance problems that led to creation of this issue were resolved by restarting phone)

Performance is generally okay, but app feels a bit janky sometimes. Need to profile app and find bottlenecks.

Pulls new posts in from ETI server using http long polling (already implemented on the server- we just need to listen)

Current just toasts the contents for debug purposes, but we really need to display the content using a MessageBuilder somehow