Home / Topic / Universal Workflow

Universal Workflow

Viewing 5 posts - 1 through 5 (of 5 total)
  • jimmycesarins7218

    One thing I would really love to see is to have Kwik manage multiple output types so you can just work with Universal.For example, this is the workflow I have envisioned.Start new project, chose name & landscape or portrait.In the same dialog is the ability create "groups", in this group you select what devices you want to support.For example, I would select iOS iPad and check off iPad & new iPad.I also create a group 2 and select Android and select all android devices.I then create a group 3 and select iPhone/iPod and check off iPhone & iPhone Retina.Now when I hit publish, it will create 3 copies of the project.  Each folder will have the entire Corona build (just like it does now) but only with the assets for the devices.  Instead of group 1 and 3, I could have made group 1 and checked iPad & iPhone and this would create two folders, one for android, and one for iOS with both iPhone & iPad assets for a universal project.  The logic is avoiding any duplicate work while streamlining each build so when you submit an app you have only the assets you want to have.  Currently if you want to make a build for iPhone & iPad separately to streamline the final app, you have to maintain multiple projects and if you change something you have to do it for each version.  This is time consuming, confusing, and more work than it could be.  By allowing Kwik to manage multiple build folders, you can automate this entire process while giving very efficient output builds.The key thing is to have Kwik create multiple output directories with the device groups you chose.  If you chose to have an android build and iOS it will simultaneously update two folders.  If you want to do Android and a dedicated iPhone & iPad release, it would create and maintain 3 folders.  All with the exact same code, but only the assets required for that build and the correct lua code to reference those devices and assets.  To make this more manageable, you can select what devices you want to build for when you hit publish, this way you can say only build for iPad for example when testing so you are not building all devices everytime you want to test in development.  In theory, it seems like Kwik could handle this pretty easily and save me a lot of time while allowing me to create more optimized builds to submit to each app store.The first thing that came to mind when looking at Kwik is how it handles building for each device.  Creating optimized builds without "double entry" which is time consuming, confusing and prone to creating errors.


    I second this option. Would love to be able to build for a specic device to help save memory.then when its time to build for another device its as simple as a push of a button.


    Ideally, we would use iPad 2 assets to do the development, and then pick what platforms we want to release it to when publishing.


    Absolutely agree. There has to be a way to achieve this. FYI I posted something similar a while back here: http://kwikplugin.com/forums/index.php/topic,532.0.html. I'm not sure the development team at Kwiksher could understand the need..


    Dear all, I do understand the need (and I am keeping thinking about it). However, this is not an easy thing to do (if so, the Corona team – at least 10 times bigger than me 🙂 would have already think about another solution). Keep reading.We are talking about 2 different things here:1) Image reduction (instead of 3 images per layer in an universal project, android devices would use just 1 image per layer): yes, there is the benefit of reducing file sizes in this approach. this is a relatively simple thing to do but, with the issue below, besides image sizes, no more benefits here;2) Screen ratio (iOS devices have different screen ration than Android devices): this is the most complicate thing (main reason Corona came up with dynamic resolution using different images). When you create an universal project all positioning is based on the 1024x768 (double if new iPad) screen ratio. Android devices varies in screen ratio so, it is almost impossible to "convert" positions to a bunch of devices - for example, an object in position 1000x700 on the iPad will not be positioned in 1000x700 on a different ratio device (for example, in the Kindle the screen size is 1024x600). In this scenario, an equation would need to be applied to ALL possible devices in the world. Also, objects would never match the "official position" during the conversion (because some coordinates would need to be increased to compensate the fractions.Lastly, as Christopher suggested, I don't agree the best option is to force all projects to be screen sized as the iPad ratio because, lots of Kwik users are only creating apps for Android devices. Setting it as iPad would not match the overall screen ratio of Android devices.Back to my point, I strongly believe (and several apps shows that) that the best approach in this case is to use the zooming options offered by Kwik/Corona, meaning 1 project fits all (you publish once, you don't need to worry about re-selecting devices when you are ready to publish.Another option is to use bleeding areas in your project (this requires a good amount of planning in the design phase). In this mode, animations and buttons will never happen close to the borders of the devices.Again, not saying I will not do anything, just saying it requires lots of thinking before trying anything real.

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.

Privacy Preference Center

Strictly Necessary

these coolies are for WP-SpamShield, gdpr-wp, woocommerce, paypal

PHPSESSID, SJECT16, JCS_INENREF, JCS_INENTIM, gdpr, woocommerce_cart_hash, woocommerce_items_in_cart, woocommerce_recently_viewed, wordpress_, wordpress_logged_in_, wordpress_sec_, wordpress_test_cookie, wp_woocommerce_session_, AKDC, akavpau_ppsd


WordPress cookie created when auto-saving a post in the editor.

wp-saving-post, wp-settings-, wp-settings-time-


google analytic