 Good evening, guys. Good evening. So just a quick question. How many of you guys are using Android phone? Almost everyone. Out of those guys, how many of you are Android developers? Let's get to here. So are you using the open human Android app? Are you using the website or the Android app? Both. Both? Yeah, awesome. So as Manan talked about the generator, I'll be talking about the Android app, what the structure looks like, and what practices did we follow during our GSOC project and how you can contribute to it. So first of all, it's not an app for Fosacea. Many people get that wrong just because the name says Fosacea 2017, it's not an app for Fosacea. It's just a template. The app you see is just a template. It's populated by the event-y server. It's populated by the event data for Fosacea. The app is just a template. It's just a skeleton sort of thing. So just to get this cleared up, it's not an app for Fosacea. If you are hosting an event, you can just create an event on event.y and you can create your own app. You can customize the whole look and feel of it. You can customize the color scheme of it. You can customize the name, the package name. You can upload it to Google Play Store. So goals of the app. What were the goals of the app when we started building this? So, kiss, not kiss. Keep it simple and keep it simple stupid. So first of all, the app should be easy to use. It should be easy to navigate. The UI UX should be simple and clean and minimalistic. It should be concise and complete. And it should be portable. So what do I mean by portable? So nothing should be hard-coded in the app. So as I said, the app is supposed to be a skeleton. So if we hard-code anything in the app, that defeats the purpose of our app. So that's the reason why you might not find the app professional as you have the apps from Google for their conferences. So if you have a look at Google iOS app or maybe Facebook's F8 app, they are top-notch apps. They are production-level apps. So we could not do that just because we don't want to hard-code anything in the app. We want the app to be portable so that if you want to come tomorrow and use our source code for your own event, the app should represent your and your event only. That's it. So features in the app. So first of all, I'll just... the guys who are not using the app. After this, I hope you'll use the app, but it doesn't make sense because the conference is already over. So probably next time. Yeah. So first of all, we have notification support. So for example, if you bookmark an event, if you bookmark a session, you get a notification 10 minutes before the event. So that's quite handy. That's not possible in the web app right now. So I was able to keep... I wanted to attend the deep-learning session, so I just bookmarked it and I got a notification 10 minutes before the session was about to start. So that's a pretty handy feature. Next up is schedule. You get a schedule. You get a view pages sort of thing where you can sort the schedule by the name or by the start, time and date. You get different tracks. You reload the web page again and again. So that's one of the reasons why we are not considering using PWAs or maybe websites just like we are sticking to apps. So that's one of the main reasons. So if once the data is downloaded, it should not be reloaded again. That's the whole thing because we all know that Wi-Fi is not stable over here. My Wi-Fi just got disconnected. I had to use my mobile data to finish my slides. So that's an issue over here. Next up is navigation. We provide navigation. This is not available in the Android variant of the app, but in the Google Played variant, you'll be able to navigate using Google Maps. So that's one thing. Next up is you can see all the speakers at one place. That's present in Web App too, but that's one thing that we provide too. You can see the sessions by location names. So I'll be giving a demo with my phone. So that'll be a bit more clear on what I'm talking about. So yeah, I'll give you a demo. Just want me to give you a demo. It's visible, right? All right. So first of all, we have tracks. It's visible, right? You can see this? It's visible. Anyone? Who's having a problem with this? You can view the sessions by their tracks. For the Android track, we have these sessions. You can click on a session and probably bookmark it. You can see the location where the session is taking place. You can share the session. You can view the speaker from the session. You can see other sessions by the same speaker. Another thing is we have the schedule. So right now, the schedule is sorted by the start time. If you want, you can sort it by the tracks. So it will be sorted by track name. Come on, man. Okay. So this is one thing that we provide also about the bookmark thing. So I just bookmarked a session that already happened and I got a notification for it. Ideally, this should not happen because all of that session is already over. So that's one thing that we'll probably fix when we get back home. So yeah, this schedule. You have bookmarks just over here. So you can view them. You can delete them if you want. You can undo the deleted bookmark. You can see the speakers. So let me search for myself. So you can visit our social links. You can visit our other sessions that we have. You can see the sponsors. They left. No problem. Next up, we have the map support. If you want to navigate to Science Center, you can probably use this. Lastly, we have locations. So if you want to attend a session in Dalton Hall, you are sitting at Dalton Hall. You don't want to move and you want to see what other sessions are there at Dalton Hall. You can click on it and see all the events, all the sessions that are happening at Dalton Hall. You can search for an event that you want. Okay. So yeah, that's pretty much about it. We have some more features lined up. Stop it. We have some more features lined up. So yeah, we'll be implementing them. And that's one of the reasons why we need you guys. The Android Devs who just raised their hands. So that you can, yeah, you. I remember you, yeah. So that you can contribute to our project. And the end goal is to make Google and Facebook use these apps rather than creating their own apps. So I was talking with Stephanie yesterday and she said that they'll probably be using for the mentor summit that's happening in October. So that's pretty great for us. And let's hope that's what happens. Okay. So next up, going forward, some features that we have planned are floor plan for the location. So for example, like, where's Fermilab? Okay. So one of the reasons this was not possible because we were not able to hard-code the data. Okay. If we were able to hard-code the data, we could just simply like made a custom UI, and allow you to navigate through all the flows. Okay. But we couldn't do this because we didn't have, we were not able to like hard-code data in the app. Next up is feedback and reviews for sessions. Video for sessions, Twitter feed, user authentication, and color system for tracks. So these are the open issues that we wish to implement in the app. So any of you guys who's willing to contribute can probably take a look at this and send up a request. Or maybe, yeah, whatever you want. That's better. So contributions, how can you contribute? So I have listed the, like, contributions in the level of, I think, importance. So if you implement the feature, that's pretty good. If you do a bug fix, that's awesome. If you are updating documentation, that's great. If you're updating build tools, that's okay. But if you are just refactoring the code and sending up a request, you are doing something wrong. Okay. You should not do that ideally. Technically, we don't, like, we follow a particular code style. That we follow in the app. So what happens normally is people who want to contribute, they just change one line in the code and their IDEs, it uses their build style, it uses their code style, and it changes all the files. Okay. So when we get a pull request, it says, like, 10,101 lines added and 10,000 lines removed. So that's a mess to review. So please don't refactor the code. Please don't. If you are really desperate to contribute, just update the documentations or update the build tools. Okay. This is a danger zone. The refactor code. I should probably remove it. I'll remove it later on. Okay. So yeah, these are some of the areas where you can, like the ways in which you can not only contribute to our project, but these are the guidelines for any open source check that you want to contribute to. So yeah, stick around the repo, like probably bug them on mailing list or IRC channels, implement a new feature, like do a bug fix. Updating documentations is very important because as developers, we don't have time to update documentation. Okay. So yeah, that's true. So our Android apps documentation is around six months old, right Manan? How old is it? Yeah, two to three months. So like that, the documentation thing was the last thing that we did during our GSOC project. So like the deadline is tomorrow, we updated the documentation today. Yeah, we don't have swagger. Okay. So yeah. So just try like, in 90% of the apps, the documentation is outdated. So that's a sweet spot for you to like contribute to the project. You can probably update the documentation. That's a good thing to do. Yeah. So lastly, what Mario isn't telling us. So this project, like we have code. Okay. We did code. We did code the whole app, but that was not the only reason that the whole open event project was a success. Okay. Like everyone is using some of the other component of open event. Some of the guys are using websites, web apps. Some are using Android apps and almost everyone used the order server for buying tickets, right? So everything, the whole work we did in the summers is like it's coming. Like we are happy to see everyone using it. So code was not the only reason for its success. So we, Mario was supposed to join me at this point, but it's a bit awkward that he's not here. So I'll continue. So yeah, let me talk about a GSOC workflow. So the workflow had a very big impact on the success of this project. So we eat, sleep, code, repeat. So we had eat, code, scrum, repeat. Okay. We had to write daily scrums for three months straight. And if you miss a scrum, you'll get an email from Mario next day saying, where's the scrum? We had this thing. So we had to write scrum. We had to write blog posts. And yeah. So we had to I pushed at least one commit every day during the whole 90 months period. So if you look my Github report at that point, it'll be just square, square, square, square, square. So like color, green, green, dark green, dark green, light green. So it's filled with that. But that's a good thing because that helps you maintain, helps you maintain your Github profile. That matters a lot. In the world of open source, everyone is using open source. So they use Github as your portfolio. I think in the next five to six years, probably resumes and CVs will be no more. People will just look at your portfolios or Github links or LinkedIn or other things. So that's a good thing. So this was a blessing in disguise. Because of the blog post, we were like, I was able to maintain my medium profile. I have around 20, 25 blogs published on Medium. And all those blogs were during the three months period. So that helped me maintain my profile at various places. So Github was one of those. Medium was one of those. As I said, we followed agile workflow model. I'm not sure what agile means. So this is what I think agile means. So please feel free to correct me if I'm wrong. So we had scrums. We had blogs. We had daily commits. So the workflow was, if you want to implement anything in the app, first create an issue for it. See, if you create a pull request without any issue, it will be closed immediately. No issue means no merge. So we had to discuss each every implementation on the mailing list or on the Gitter channel that we had. There used to be a one-to-one mapping between the issues and pull requests. If you are sending a pull request, that should solve only one-in-one issue only. You cannot have multiple pull requests for a single issue. Or you cannot make a single pull request that is solving multiple issues. So that should not happen. And I think that's a good thing because that makes the work of maintainers easier. So now we as a mentor, when I see other people contributing to the project, I ask them to follow this model because I have my day job. So I am doing open source as a part-time job. So during that time, if I have to go through a PR which adds 10,000, one line and removes 10,000 lines, so that's pretty much absurd. I won't merge it straight away, close it. So this model, I think we should follow it every each and every open source community should follow it. You should have clear documentation. You should have clear templates in your GitHub repository. So I can show you the template that we are using. So if you go to the open event repository, yeah, this is it. Okay, Wi-Fi is not working. That's awesome. I'll probably show you it on my phone. It works. Visor works. Okay, it's working. So see, if you try to create a new issue over here, I'm not sure where the issue is. Okay, it's here. So we'll ask for some things. So what's the actual behavior that you face in the app? I'm not sure if it's visible. What's the actual behavior? What's the expected behavior? What are the steps to reproduce it? What are the logs? What's the screenshot of the issue? So that makes the work easier. That helps us to see if that really is an issue or that's an expected behavior. That's an issue. So what issue that pull request fix is? Okay, what are the updated screenshots for the app? And things like that. So if you see our pull request, okay, so he's not following the guidelines. That's bad. Oh, that's bad. None of the guys are following the coming guidelines. Okay, so you see. So this fixes this issue. Okay, these are the screenshots for changes. And that's it, yeah. These are the two things that we want. So why this thing? Because whenever you merge an issue that fixes work in front of it, if you merge this PR, the issue related to this PR, that issue number 1300, will be automatically closed. So that reduces the workload of maintainers. So these are things that are put in place by GitHub. So we just leverage them. And it makes our work easier. This model has been adopted by a lot of other organizations as well. Yeah, so I think what was the mailing services that we used for the app generator? Send grid. I was inspired to use this thing by send grid. So I was facing a problem while implementing send grid in the APK generator because we need to send the email containing the generator APK, right? Yeah. So there was some issue with their PHP library. So I just created an issue and they asked me all these things. So what is the PHP version you are using? It's the Linux version you are using. So all those things. So I was inspired. I thought we should do this too. It's pretty awesome. It's pretty neat. I think everyone should use this. And it's pretty good. It's pretty good. Okay. So that's almost it. So if you have any questions, so just let me know if you are interested in contributing. So stick around. I'll give you some pointers on what issues you can work. If you want to participate in GSOG with FOS Asia, let us know. I'll be mentoring the GSOG guys this year. And yeah. Thank you. Any questions? No one? Come on, Android guys. No question. None. That's sad. You should ask questions. I'm not sure. I'm not sure about that. Okay. Thank you so much. Mario was supposed to be here. He was supposed to conclude the session. I'm not sure what Mario isn't telling you. We should probably leave this up here and wait for Mario to come. This has been recorded, right? I should probably close it. Okay.