Closed kimdv closed 6 years ago
So contribution should not be available for the public?
I still think we should fetch data somehow from iTunes. Otherwise we should manually keep data up to date. (If they change the name etc, app icon or so)
The contribution can be public in order for people to let us know about new HomeKit apps. Using the iTunes Search APIs would be no different than searching in the App Store directly, so it’s no use to our users. Instead, by providing them with the already known and best HomeKit apps would definitely be interesting and helpful.
So the contribution should be like the accessory. Only with name and link? No more additional information ?
@kimdv yeah, it should be similar to the accessory. We should ask information such as name, link, icon picture, website and price.
Hey @kimdv, is there anything blocking this PR or may I know its status? 👍
Hi @BalestraPatrick !
I have been busy with work. It should be first attempt to HomeKit apps and app page. I think I need to do some little refactor, and adjustments before release 😄
@kimdv Sure, no worries at all! I appreciate your help, just ping me and remove the WIP status when you feel ready 😄
We also need some sort of report page here. Should we extend the correct report and with "Report app functionality" ?
@kimdv We can extend the usual report and simply add an option to select the app from a dropdown similar to the one we have to select the accessory now.
Should the manufactor / developer be the same?
A lot of the manufactures of accessories develop their own app?
@kimdv Yes, I think we can have a single publisher
data to store who is the developer and publisher.
hmm, I don't quiet follow?
Should we have a Publisher
table and refer to the manufacture if etc. Philips release Hue App?
@kimdv No, I mean that each app object should have a single publisher property of type String, to store the developer of the HomeKit app.
So no foreign key to a manufacturer or developer in case of multiple apps?
No, let's keep it simple for now :)
Hi @BalestraPatrick !
I think I have something that is ready for first feedback!
I have had a bit trouble about the contribute page, because if we mix it with the current, I think it gets a lot messy with a lot if app then this otherwise that, if you can follow me?
@kimdv The PR looks good, just a couple of points to modify before we can proceed to deploy this to staging for further testing:
Regarding the "report issue" do you think something like this
I think it is double with the report issue, because it is already at the bottom of the page.
It is possible to add subtitles to iOS apps as in iOS 11 App Store. So I think we should keep it.
@kimdv We can remove the contribute and report issue on the right if there are no apps to browse. Regarding the subtitle, I know what you mean but the subtitle is optional in the App Store. For example, if you search the Philips Hue app, you won't see any subtitle. Let's make the subtitle optional and display it in the app details page only if present.
I think I got the most now!
I think we should reconsider the contribute at top of the page, and move it down under all the accessories like the apps.
Or we should add a 2 step contribution.
One pointing to apps and one to accessory
@kimdv Yeah, splitting the contribution in two pages makes sense, so we can clean up the code a bit. Can you take on that? I will do some small UI modifications to the sidebar now.
Should I add it to thi PR?
@kimdv Yes, that sounds good!
hmm, I have added a simple link. But we should maybe add some describing text or some images, because it is really empty that view
@kimd What page are you referring to? I just tried the project and the "report" button is not filling in the details of the accessory in the form. Try pressing the "report" button when on an "App Details" page.
@BalestraPatrick I added some performance fixes so the iOS app, manufacture and accessory counts are fetched in one request.
Fixed the linking. But I can't reproduce the "report" issue. Mine forms are filled correctly. What view are you looking at?
@kimdv If you add an HomeKit app, and then go to its page (i.e: http://0.0.0.0:8080/apps/2) and press "Report Issue", it will go to http://0.0.0.0:8080/report
but at this point the dropdown menu is not selected with the accessory where the user want to report the problem?
For the accessories, we pass the id
to the report page in this way: http://0.0.0.0:8080/accessories/804/report
By doing this, when rendering the report
page we can already pre-select the correct accessory of the issue for the user.
@BalestraPatrick fixed!
@kimdv I made some cosmetic changes to the form and some bug fixes myself of little issues that I noticed, and now this is ready to be deployed to staging! 🚀
I was thinking to ma sully curate the list of HomeKit compatible apps to have an higher degree of quality of the apps we suggest. The iTunes Search APIs May be an overkill for use since they return a list of results.