Hi @Kop3sh,

Thanks for opening this issue and taking a lead on adding Mobile Android/ iOS Support.
One of the reasons we chose Flutter was to ship API Dash across all platforms one day. Adding Android/ iOS support will definitely be an ambitious project and will require a lot of work, but your step-by-step approach is definitely the way to go about it. Before you start coding Step 1, do share the UI mockups for smaller screens in this issue thread, so that we can discuss what would be the best way to adapt the UI for mobile. Also, do join our Discord server and ping #foss channel in case you need any help.

Hi @animator

Thank you...

I'll get to it then.
It would be great if you could share with me existing UI mockups/ components/ themes... so that I repurpose them and follow the same design rules without reinventing the wheel and wasting precious time ?

We do not have separate mockups currently as we are using Material 3 as the base. And any tweaks made and all reusable components of API Dash are present in lib/consts.dart & lib/widgets/.

Also @Kop3sh, by mockups, I just meant simple rough drawings to show what elements (button, tabs, fields, etc.) will go where for smaller screens. There is no need of very elaborate mockups with full themes. Just simple drawings to discuss on the layout.

https://drive.google.com/file/d/1guo6oZV66xbIOzYTyuVBF7VdBEcJ7od1/view?usp=sharing

This Google Drive link contains a rough sketch of the mobile layout.
looking forward for your input/ suggestions...

NB.
Please let me know if there's a solution for saving a cloud centralized excalidraw sketch for easier collaboration.
I tried the 3rd party extension for google drive but it returns this error "Request had insufficient authentication scopes."

Hi @Kop3sh, I think you can continue using excalidraw if you are comfortable with it. There is a Google Jamboard where people can collaborate. But, I am not sure if it has advanced features like excalidraw. Anyways real-time collaboration is difficult due to timings, so having iterations in the form of comments in this issue thread may actually be better as we can go back and refer to any iteration anytime.
Also, instead of uploading on google drive, it would be great if you can just drag and drop the file in the issue comment as an attachment as it will remove any external dependency (google drive).

I did take a look at the schematics and it has a lot of ideas and I am going through them one by one. Please give me a couple of days to work on it so that I can review all the aspects and add my inputs.

Thanks! 🙂

I've already tried the darg-and-drop thing, but apparently github "doesn't support this file type"...

Hi @Kop3sh, It does support compressed file upload .. all you need to do is compress (.zip) the file and drag & drop.

Hey! Is this issue underway? If so would love to work on it

Hi @Manas-33,

Right now we are in the design stage.
@Kop3sh is currently working on the issue and has attached initial mockups which I am currently reviewing.
You can also take a look at them at your end and also include your feedback in this thread.
It will definitely add another perspective and help this issue.

Yup, would love to contribute 👍

@animator any updates/ comments on the mockups

Hi @Kop3sh ... got swarmed with some new feature reviews.
I have made some notes and mockups.
Please give me 2-3 days to get everything sorted.
Apologies 🙏 for the delay 😞

sure, take your time
and good luck with your reviews

@animator
I hope you're doing well...
Any news about the mockups stage, so that I can move forward with the next steps

Hi @Kop3sh, Extremely sorry for the delay. It won't happen again.

Option A

Option A Feedback:
It looks like a more natural extension of our existing app. Just a few pointers:

• Missing Send Request Button
• As the size of screen is small we should optimize on space, like a dedicated row for HTTP Verbs is not required as we can directly add a dropdown for verbs at the top. But, I also like this method of selecting method via chips too, so maybe we can create both versions and see which variant has a better UX when actually used in a real device.
• The section to show code is missing.

Option B

Option B Feedback:

This is a new design where we are hiding details in the sliverappbar. It may confuse some users as this kind of interface is not that common in mobile apps.

Both versions have elements that we can definitely use in the mobile version.

Also, few other points for the mobile version:

• It should have all functionalities of the existing desktop app.
• It should not be drastically different but a mobile friendly version of the existing app.
• We should be able to reuse as much existing code as possible to make it more maintainable.

I have taken some elements from option A & B and also added some elements from my side to create the below iteration.

.

.

Do let me know your thoughts on this iteration and please feel free to share any modifications below.
Thanks @Kop3sh !

No problems...

I totally agree with what you're saying, I'll get started with coding, if it is okay with you...

Sure @Kop3sh you can definitely get started. 👍

Hi @Kop3sh @animator can i be of any help?

This pull request serves as a starting point, I plan on following more of an iterative approach, -if it is okay with you- just to make sure that I am going with the right path...

waiting for your review and guidance

@AbhinavISM sure,

I am not proficient in writing flutter tests, maybe we can collab on that, if it's okay with both of you @animator

N.B. it's just a suggestion, feel free to help out with whatever you see fit...

i have started writing tests only recently too, we can do that together.
is there a way i can help with mobile ui too? since you have made changes and made a PR, i see you have enabled ios only till now, is there a way i can help with andorid parralely? maybe just tell me to do something, eager to help

Hi @Kop3sh Thanks for sending the PR .. I will definitely review it.
@AbhinavISM, @Kop3sh is currently taking a lead on this issue .. so some of the ways in which you can contribute are:

• Testing PR Initial Mobile Support #70 on iOS & Android and providing your feedback and how it can be improved.
• We have shared design schematics above. You can also take a look at them and provide your feedback.
• Writing Flutter tests for mobile version (which will come at a later stage as we are currently in the early stages of the feature dev).

@opxdelwin , as per the rules of GSoC you can discuss ideas on this thread but you cannot work as a team. Please feel free to share your views on this thread and send across a PR implementing your vision for API Dash mobile app.

Hi @ashitaprasad,

I've generated Android and iOS files for the project and addressed some issues to ensure the app runs smoothly on Android. Could I go ahead and create a pull request with these changes?

Sure @Yousef-Rabia, please go ahead and raise a PR.

Hey @animator @ashitaprasad
My design proposal for the mobile layout with maximum reuse of existing components.
Figma Link
What are your thoughts?

@DenserMeerkat looks fantastic 👍

@animator These are amazing designs that you have created but there are few things that I would suggest you to must add in the design for better user experience.

• Collection creation, I would suggest you to show collections within the collection there will be multiple requests.
• More Options within each request there must be an options like edit, duplicate, delete etc
• Save button on homepage, to save the request in the local storage using Hive

When a user click on the requests from the drawer, API request should have to execute it on the home_page screen.

Hi @animator @ashitaprasad

Having reviewed @animator's mock-ups, I find them closely resembling the desktop client, promising a positive user experience within limited screen space. I propose initiating mobile client coding based on these mock-ups, with the flexibility to incorporate UI/UX enhancements during the development and testing phases.

If you agree on this I have some quires after going through the current desktop client codebase. I believe we want to develop a mobile client in a way that ensures modification to functionalities in future won't require change in both desktop and mobile client specific files.

So we can:
a. Maintain one layout file for desktop and mobile client by maximising the use of ternary operators.
b. Having a different mobile layout file, but using the same reusable components as desktop client.
c. Prioritising a but using b if ternary(if-else) nesting increases.

I have gone through the code base so if you want you can answer section specifically as well. It would be difficult for me to give an example on text. If you did not understand and if you want we can hop on a call and discuss it.

@DILPREET1910 point b with as much reuse of desktop components as possible.

@DILPREET1910 point b with as much reuse of desktop components as possible.

ok thanks got it!

Hi @animator @ashitaprasad
I read issue, saw mock-ups that you created and fork repo.
I think it is interesting issue, I have some Feature idea we can add and design with as much reuse of desktop components, so can I make design for app and show you or I should put my design and features in my proposal?
also I saw bug in mobile app, It is normal because it not ready yet or I can fix it and PR?

@MohammedAshraf19 send across a PR to discuss further on your implementation.

@animator @ashitaprasad @Kop3sh Hey everyone! I would like to start working on this project for GSoC'24. Can I start building the ui/ux or mockups for the screens? I really have a keen interest in this project, and I would like to contribute.
Also, do let me know what is the current status of the project, what is built and what is still left?

@animator @ashitaprasad @Kop3sh Hey everyone! I would like to start working on this project for GSoC'24. Can I start building the ui/ux or mockups for the screens? I really have a keen interest in this project, and I would like to contribute. Also, do let me know what is the current status of the project, what is built and what is still left?

Hi! Have you cloned/forked the repository and run it on your system? Some work seems to have been done on the issue in the past weeks (and months), as I can see Pull Requests made -- 1 merged, 3 open.

@GeekyMonk07 @Detective-Khalifah You can build mockups of the design and submit your implementations via PR. We are reviewing all the open PRs and will provide feedback for the same.

Hi People. I am intrigued with the idea of the app client, I would be grateful if someone could update what they are expecting now as some work has already been done in the past.

@chiragtyagi2003 see this comment

Hi @animator as you mentioned we don't have the app yet, if the project is still open I would like to shift my focus to this.

Hi @animator @ashitaprasad, I build some initial mockup for the drag and drop functionality and I wanted to pick your brain on it to make sure I am heading into the right direction or not.

Now I am working on making UI more feasible and user friendly, but if you could guide me if I am heading in the right direction, and also what else to add.

@chiragtyagi2003 This UI does not align with the theme of API Dash. Would recommend you to go through the above thread in detail and understand what options have been suggested and why.

@ashitaprasad I am changing the UI to align with the app's theme, just wanted to make sure about the drag and drop function, in case I am heading in the wrong way.

Hey @animator @ashitaprasad
My design proposal for the mobile layout with maximum reuse of existing components.
Figma Link
What are your thoughts?

Hey man it's looks great man 👍