OSCAL is an event using Open Event. The API is here: https://eventyay.com/api/v1/events/47
Please test the app with this event and report issues.
@mariobehling The app is working absolutely fine with the API. One thing which I noticed is that the track opening speech is been added twice which is causing redundancy and can be removed. Apart from that everything is fine. :+1:

@mariobehling Everything works fine on all fronts (except the redundancy @harshitagupta30 mentioned)
@mariobehling Should this be closed now?
@iamareebjamal @harshitagupta30 Thanks for looking through the app. On a quick glance things might look ok, but did you really go into detail? As we are planning to work together over the next few months more attention to detail is necessary.
Can you really go into detail, please?
Did you test all links in the app and compared standard behavior with other apps? Is the design and structure of the app flow consistent. For example why does not the detailed track view show "Day 1, Day 2, Day 3" like the web app of FOSSASIA and the schedule page of the app? What about the resolution of the image in the menu sidebar? What about the size of the logo in the opening screen? Is the logo of the opening screen the event logo or always FOSSASIA?
What issues do you find? Can you dive into very tiny details, please and tell us what needs to be improved? Is this already a world-class app that gets you excited?
Did you try to create an event for 4, 5 or more days? Does the UI work in that case? What works different in big conference apps like Google I/O and F8, that we don't have? What information we have in the FOSSASIA APIs that are included in the app, e.g. where is the Code of Conduct? What else is missing?
Please test in more detail and provide your - deep - insights. Thank you.
@mariobehling Yes, I get this that development process is a little bit slow. There are some inherent code structure issues that slow it. We are trying to improve it. The biggest restriction is that the app is not a standalone one, it is generic which needs to adapt according to the Event provided or even the API structure. Unlike F8 or Google I/O, we cannot brand our app with specific graphics and UI design, we have to keep it generic and within the Material Design Guidelines so it remains neutral. F8 follows its own design structure and I/O app has heavy personalizations which cannot be incorporated in any generic app. Like I wanted to make the app image content rich but unfortunately most events and tracks don't provide images so its mundane to rely on that whereas other apps like I/O have static data and their app is built around it, not the other way around.
About the app feature set differing from the web app, I agree that I personally didn't know which should be the standard way, which feature should follow which app's design philosophy. I learned the API and server implementation a month ago and found the app lacking on some fronts which can't be handled unfortunately, because -
Furthermore, conforming with server makes it hard to add features off the top of our head, like adding notes, reviews, social media integration, etc because handling it inside application won't make any sense and make both server and app incoherent. This point also stresses why rapid prototyping works on other standalone apps like F8 or I/O.
The edge case handling you mentioned like handling of 4, 5 day events, etc didn't even cross my mind because of the issues existing in the application, like the lag on the swipe or on click on the navigation drawer(which, trust me, is not easy to fix as it is a bug in support library itself). To fix many of those, I am constantly looking at other open source projects like Telegram which has tackled it.
The lack of tests is another issue and I wanted to start on it as soon as possible but it would be very hard to do regarding the current architecture and storage options(SQLite) we use. Almost all projects now use better and reactive database management solutions which are faster, easy to test, and don't break the application when updated. To write tests on current stack would only waste time which could be used to fix more things. Changing these things require collaboration and time and I am certainly sure that together, in a few months, we will definitely have a better app to develop and maintain on
@iamareebjamal Excellent input. And yes reading your ideas, it becomes even more clear that devs need to align and understand what is going on with development in the server app pro-actively.
The Android app generator is not a separated project, where devs simply need to wait for the Orga (future API) server. As the team is working to move to a more API centric approach we need more input from the Android team here as well. The Android team needs to engage more actively in the development of the APIs, open issues and provide feedback.
And we also ultimately want other cool features. While social media features, live streaming and what other cool stuff would be great for the app as well, firstly let us focus on the actual event itself for some more time now and see what other data we can get from the existing APIs already, e.g. video links can already be provided in the APIs, but I have not seen that implemented in the Android app.
Regarding alternatives to SQLite, please open an issue, where this can be discussed separately and propose an implementation. Please estimate the time for development.
Thanks a lot!
Would be great to get more such input from others as well. Cheers.
@harshitagupta30 Hello, I am one of the organizers of OSCAL. After generating the app, as always I found the app to be named FOSSASIA 2017 and the splash screen same thing. I managed to fix those by modifying the APK, but the problem here relies in the session times, they seem to be wrong, for example the event starts at 9 AM but there it shows 3 AM, so this means it fetches the time as if it were somewhere else and not in Tirana which is GMT+2. Can you please take a look at it and try to apply a fix? Unfortunately I am not a developer so I cannot do much but I believe this is related to the eventyay API that needs to implement the GMT+2 time element in it, so the times show up correctly. Thank you.
Hi @AnXh3L0, we are extremely sorry that you faced such issues and thanks for reporting. Currently, when the app is generated using the generator it takes the default app name and logo due to which you're seeing FOSSASIA 2017. Also, the time is set according to UTC standards which need to be changed in the eventyay API. If you require the APK of the application ASAP for testing then the one way is we can manually generate it by replacing the API's link in the code and provide you with the APK which will not give you freedom to generate it using generator but the ideal solution is to fix these bugs in the generator and let the user enter the details about App's name and the logo and the other details which will take a little bit time not much but a day or two. Please let me know if you require urgently. We'll be anyway updating the generator resolving these bugs.
Thanks :+1:
Hello again @harshitagupta30 . Thanks for the quick answer, TBH, the conference starts next week so we would love to have the app ready because the agenda should be ready already, so we don't expect new changes. If you can provide me with the manually generated apk file I would appreciate it a lot. No need for you to change the logo and name, I can do that, all I need right now is that the session times are correct. Thanks in advance.
Thanks for your quick response @AnXh3L0. I understood the issue related to the timings. I'll try to provide you with the APK after fixing this issue with correct timings ASAP.
Sorry for the inconvenience.
Thanks.
@mariobehling I need a help from you. Actually the link of the eventyay API you have given https://eventyay.com/api/v1/events/47 in which the timings are currently set according to the timezone UTC+0000 which need to be changed to UTC+0200 Europe/Tirane to display the correct time. Since you have created the event on Eventyay and I don't have the permission to change so, it would be very great if you can update the timezone and let me know so that I can check and verify. Thanks :+1:
@AnXh3L0 We'have resolved this issue of displaying incorrect timings. I am also attaching a modified APK with correct timings. Please check it out and let me know if any other changes required.
Oscal apk.zip
@harshitagupta30 Thank you, it works fine now although I cannot edit the splash screen haha :D
@harshitagupta30 Please change the splash screen logo too for the OSCAL apk please. Thanks!
I can send you the file we want to use as splash screen because I couldn't edit that by modifying the apk file. Also, I noticed that the sidebar event logo would change after opening the app after the 1st time to the fossasia one. Just reporting bugs here, please PM me so I can send you the splash screen image :)
Thanks @AnXh3L0 I'll look into the app drawer issue.
Sorry for the inconvenience again

I tried loading the app several times and even after rebooting the phone, it loaded the correct logo. Can someone else please confirm the bug as I can't replicate it
I hope it is only for me then. Adding a new splash screen and the app should be ready to publish.
@AnXh3L0 Please attach the image for the screen here itself. Thanks :+1:
@AnXh3L0 and regarding the logo that is because it's been loaded by the server so sometimes due to weak internet connection it's not updated and therefore you see FOSSASIA's logo.
@harshitagupta30 But the logic should be to load the app logo instead, IMO. The generated apk should not contain any reference to the fossasia resources and hence shouldn't show the fossasia logo.
@iamareebjamal got your point. We're currently using Fossasia's logo as a placeholder which needs to be changed I guess. (p.s. I am not much sure about this need to check in the code)
@harshitagupta30 attached is the splash image :)

also, @harshitagupta30 , if possible, can you add the image attached as the app icon? the one right now seems too big to me :P thanks a lot btw :D

@AnXh3L0 sure! I am changing both the app icon and splash screen icon and will attach the APK here.
@AnXh3L0 Here goes the required APK, now you'll be no longer see Fossasia's logo and all the required changes have been made. Cheers :+1:
oscal apk.zip
@harshitagupta30 ugh

@AnXh3L0 oops! Sorry please, find the updated one.
oscal apk.zip
@harshitagupta30 Thanks a lot, it looks great! It is now accessible to everyone by visiting http://osc.al/app
@harshitagupta30
In schedulefragment it still shows day 1 & day 2
@free4murad I know, I forgot to update the code but in my opinion that is not a big issue for which the app needs to upload again on the website and cause inconvenience to the organiser :) I am sorry but it will work here I guess :)
@harshitagupta30
Please, no need to be sorry. It was just a reminder.
Most helpful comment
@mariobehling Yes, I get this that development process is a little bit slow. There are some inherent code structure issues that slow it. We are trying to improve it. The biggest restriction is that the app is not a standalone one, it is generic which needs to adapt according to the Event provided or even the API structure. Unlike F8 or Google I/O, we cannot brand our app with specific graphics and UI design, we have to keep it generic and within the Material Design Guidelines so it remains neutral. F8 follows its own design structure and I/O app has heavy personalizations which cannot be incorporated in any generic app. Like I wanted to make the app image content rich but unfortunately most events and tracks don't provide images so its mundane to rely on that whereas other apps like I/O have static data and their app is built around it, not the other way around.
About the app feature set differing from the web app, I agree that I personally didn't know which should be the standard way, which feature should follow which app's design philosophy. I learned the API and server implementation a month ago and found the app lacking on some fronts which can't be handled unfortunately, because -
Furthermore, conforming with server makes it hard to add features off the top of our head, like adding notes, reviews, social media integration, etc because handling it inside application won't make any sense and make both server and app incoherent. This point also stresses why rapid prototyping works on other standalone apps like F8 or I/O.
The edge case handling you mentioned like handling of 4, 5 day events, etc didn't even cross my mind because of the issues existing in the application, like the lag on the swipe or on click on the navigation drawer(which, trust me, is not easy to fix as it is a bug in support library itself). To fix many of those, I am constantly looking at other open source projects like Telegram which has tackled it.
The lack of tests is another issue and I wanted to start on it as soon as possible but it would be very hard to do regarding the current architecture and storage options(SQLite) we use. Almost all projects now use better and reactive database management solutions which are faster, easy to test, and don't break the application when updated. To write tests on current stack would only waste time which could be used to fix more things. Changing these things require collaboration and time and I am certainly sure that together, in a few months, we will definitely have a better app to develop and maintain on