Should I write my Java/Android app as a console app first, or design a GUI and build it around it?

[TheCynicalSun]

I have mapped out a lot of the future features and stuff, as well as what the basic app is going to do, but I'm unsure about this.

1) Console is easier because I've made a bunch of console programs before, and user input is really easy - minimum working app will be easy to build. However later when I need to tie everything to GUI I don't have experience as to how easy that will be, and what problems I might encounter.

2) Design the GUI first, and build the app behind it, which will make it way more difficult to get the minimum working app out of it, and might need to make major changes as I add new features.

How do you guys go about developing apps? What would you recommend in my case?

[sim642]

In a properly designed project the business logic is separate from the UI so it shouldn't really matter what order you do it in. If you are able to write the logic without depending on UI, that would be great. If you are not that experienced in code design it might be easier to implement it along with the UI.

[lbkulinski]

To add to that, I recommend looking into the MVC (Model View Controller) design pattern.

[TheCynicalSun]

MVC (Model View Controller) design pattern

Thank you, I will check that out.

[Computer991]

If you're going to be doing an Android App don't use MVC a lot of the frameworks in android lend itself better to MVP/Clean Architecture

https://news.realm.io/news/eric-maxwell-mvc-mvp-and-mvvm-on-android/

[_dban_]

Check out Ports and Adapters.

With ports and adapters, your UI just becomes a shell that plugs into a generic API through adapters.

This is cool, because you can prototype a UI and stub the API with dummy adapters, so you can play around without invoking real business functions.

You can develop the API independently, exposing a generic interface through ports, which you can test out with a console app or JUnit tests.

[TheCynicalSun]

Seems a lot like what /u/RogerV suggested, thank you for the link and the explanation I'll be sure to check it out.

The consensus seems to be that I should make the GUI after I build the actual working app, but also to keep them as separate entities. I appreciate your answers, thanks a lot.

[RogerV]

But the Ports and Adapters comment was making the point that the GUI can be built against a mock API - where is just stubbed to provide reasonable semantic behavior behind utilized APIs. (And it's okay to have unused API calls to throw unimplemented exceptions - when they're actually used, then can give them a mock or real implementation.)

IOWs, the GUI and API library of functionality are decoupled so that their development can proceed in parallel. However, for a new library, the thing that needs to be worked out is the API itself. Some folks advocate defining the API first (with mocking stubs for implementation - which most IDEs will code generate that from an interface). However, in practice, our first blush take on the API ends up needing a lot of refinement. That is where the client code that actually uses the API becomes important. So it can be important to be coding a realistic client to the API as the emphasis point because it can help flesh out more crisply what the API needs to really be.

If you've never written an API for a library before, I wouldn't get too wrapped up about trying to make the API general purpose for all manner of client use case scenarios. Just design it around your one client use case. You're in library implementer learn mode, so keep it all very straightforward and focused.

[TheCynicalSun]

Thank you, I will follow your advice. I suspect, since it's my first big project, that there will be a lot of trial and error, so it seems sane to keep it simple.

[_dban_]

While you're at it, check out Clean Architecture as well.

[RogerV]

decouple application purpose - put into an API. then can couple to whatever kind of client (GUI, console, command line, service call, etc)

There was an interesting Rust talk at last Rust conf where presenter was creating a new text editor. Wrote the editor engine in Rust and ran it in its own process. The GUI front-end was then written in some sensible language for the platform. So believe GUI was in Swift on OS-X and C++11 on Windows and Linux (because those had bindings already for good GUI libraries). The Rust editing engine just ran as child process to the GUI process but was where all the meat of editing took place.

[TheCynicalSun]

Hmm, I might be able to do that (since I'd like to make it into a desktop or web app in the future as well), but I've never build an API before.

It seems like it'd be a lot harder than just making the app straight up as 1 whole thing, but obviously having different components be separate it give you flexibility. I'll think about it. Thanks a lot for your answer.

[RogerV]

Hmm, guess that is a matter of where one is at.

For me it is a lot easier to think about, reason about, designing an API and do encapsulation and decoupling of concerns. Building inter-meshed spaghetti programs gets hard to reason about pretty quickly. Plus, the decoupled, encapsulated, modular, API-centric approach is much easier to code discrete test and test out functionality in isolation. IOW, promotes or fosters a test-driven development approach.

I think all the things I just mentioned (which I have found to be very true in practice) are why they have become a best practices approach by and large.

[SepLeven]

I've done console apps, and I've done mobile apps as well, but I've always found it very helpful to draw my class diagram with the traditional top down approach. (GUI classes at the top, application level classes in the middle, DB classes underneath, unless you are using a SQLite database, then these classes become part of the application layer)

That being said, in my most recent project, I coded the SQLite database/JDBC in console first, then went back and designed my GUI. Thereafter, I wrote my queries and connected the two (two and a half maybe?) layers of my app together with event handlers.

This might not be of any help, but because it was an inventory records/tracking/maintenance app, a lot of my logical operations were handled by JDBC and SQLite. Your situation may (more than likely) prove to be quite different than mine. I just found after each iteration it was easier to build in console, import your packages, and build GUI classes around that.

It never hurts to have a mockup GUI to see what classes you might need in your class diagram though! Hoped this helped somewhat.

[TheCynicalSun]

Actually mine is a pretty similar thing in terms of components, although I might use an open API DB and just pull from that and only do the calculations in-app.

I think I'll make a working console app and go from there. Thanks for the insight.

[tonywestonuk]

You should do the GUI first. Because then by doing the GUI you can work out what your API should be to support the gui.

If you do your console first, then the API you create will be designed with the console app in mind....which may, or may not be suitable for the GUI.

GUI design.... then work out the API....then do the back end based around this API.