The final release is planned for Q4 2015 - UC Q&A | 2015 Esri User Conference
".. publishing to app stores will be easier..."
Could you please expand on this? The AppStudio team is keen to hear about real user experiences here. At the user conference we spoke to a lot of people, and when we described the current process no one expressed deep concern about taking the installation files that esri generates for you to the stores. Of course some people may not have fully understood the steps that are required, but they were at ease that some effort must be completed at their end to ensure it was their own app and branding that was in the store.
The most elegant solution would indeed be to press a button and your app automagically appears in the store. However, this is more a business problem than a technical one. Who owns the app? Who signs the app?
So back to my first question, could you please expand on what part you'd like to be easier, so that the team can focus efforts on what will make the biggest impact in the publishing process.
Thank you for your reply.
When I mentioned "...publishing to app stores will be easier..." I was referring to something I read at: Distribute your app—AppStudio for ArcGIS Desktop Edition (Beta) | ArcGIS Towards the end of this page there is a title: "Publish to Store service—Coming soon." It mentions the following:
It says that the Publish to store service is intended to be provided at release time, which is what made me want to clarify the expected release date. I also viewed the following video:
"AppStudio for ArcGIS: "Building Native Cross-Platform Apps." In this video at minute 45:45 it says: "...we are expecting to go final around June/July 2015."
I am still learning the process of how to publish an App to Apple App Store and Google Play. If there were options within AppStudio, or even a wizard to guide the user through the publishing process this would be great.
Thank you for the expansion.
First to clarify the release story. Our release date has now pushed out later since the time of that video. The July time frame has now become our public beta. Our expected final is now the end of 2015.
Regarding the bullet points describing publishing, we have now collected a lot of feedback about these two concepts and are reconsidering what our final position will be. Please do tell us what you think of the following:
Provide your own code signing credentials
This is proving to be more of a business problem than a technical one. How are certificates managed? Are customers willing to share certificates? Who is responsible for the content of app? What happens if an app is rejected by a store?
Our current thinking is to instead provide more instruction (videos, tutorials) on how to manage the store process yourself for your custom apps.
Nominate Esri to publish your app
Similar to above the key issue here is ownership and responsibility for the code.
Our current thinking is to only offer this option for apps that are built from our web templates only. Only configuration that can be accomplished on the web will be accepted. If you were to download and customize the app on the desktop you would need to follow the videos and tutorials to publish your app yourself.
Customisation is something that is important to me. Making input fields bigger is one example of a customisation. Ideally it would be great to be able to customise the app and have ESRI publish it. This can be solved if the size of the input fields could be modified from within the web interface.
By your description I'm guessing your talking about the Quick Report template - is that correct?
Interestingly, your question has revealed a couple of things that we need to work on:
- there is already a property called baseFontSize that can you can set to scale up or down all text/input sizes
- this property currently can only be set on the desktop - but yes it could be made available on the web - we will work on that
- this property currently is broken . If you were to set it in the desktop tool (as i just did) you will not see a change in the app. However, I was able to make it work by changing one line in the app. we will work on fixing this too.
Tip: if you need this right now, go to the file QuickReportApp.qml and change the line
property int baseFontSize : Math.min(app.info.propertyValue("baseFontValue", 20), 20 * scaleFactor)
property int baseFontSize : app.info.propertyValue("baseFontSize", 20)
The current property does scale ALL text, so we might need to consider adding properties that distinguish between label text and edit text. Please tell us what suits your apps.
But back to your original question, we do need to find an optimal amount of configuration that we can offer in the web so that we can provide a useful publishing service to users.