I want to refactor the biggest part of the app on which I work - and it is pretty much spaghetti. It's a single class that makes the requests to the server, parses the JSON and saves the data in the database (it also has knowledge of some UI that needs to change when specific business rules are met and it definitely shouldn't know all this stuff). It has somewhere below 5000 LOC :(.
One way of breaking the class in smaller pieces would be to separate the requests by semantics (for example User requests, Search requests etc). Would that be useful or not really?
Also, I think that networking code should be decoupled from the parsing code and also from the DB code. The problem is that I don't really know what approach (architecture/design pattern) should I use to do this the best way. (for example, our JSON parsing library is old and is not maintained anymore - we wanted to change it because it produced some problems and we were stuck because of the tight-coupling).
I also would like to receive some suggestions for the following issue: We use the DB mostly for offline mode & caching. The user can see data in offline mode, modify it (and requests get serialized) and when he gets back online, the requests will be made to the server. We also use it as a cache to show something on the UI while we do a request in the background to see if there is new/modified data (we use a similar mechanism like ETag to check with the server).
So this is the flow when a user enters a screen:
enter_screen -> check_cache + background_request -> show_UI with cache data -> update_UI when the background request finishes and new/modified data is available.
Can this stuff be abstracted away somehow? I was thinking of some kind of delegate pattern where I get an immediate callback when I hit the cache and then get a later callback when the request finishes (with optional flags to distinguish between cache and fresh data).
A bit of a background story
I currently work for an iOS app that is aprox. 4 years old. I only joined the team a year ago. In my opinion the code is ugly, full of hacks and has a very shaky architecture. We are 2 iOS developers working on it. The client doesn't have technical expertise and may not understand all the implications of some issues that we have. Making a client to understand why "refactoring" is needed, is a hard task. I struggle to refactor how much I can, but we still have a lot to go trough.
The app also has a lot of features that increases the complexity of the app: deeplinks, push notifications, offline mode, non blocking UI etc. all combined with a rather large and hairy data model.
Because the client requests features in a constant manner, I feel that we have a lot of technical debt.
The mobile world is changing pretty fast and new technologies appear (Size classes, Auto Layout, Swift, etc.). This is true for all technologies, but I somehow feel that the race is a bit more intense in the mobile world. Currently I only dream of using Swift at work (although I play with it at home in my spare time).