jameslongman / squad-mortar-calculator-ios Goto Github PK

Under the 'More' tab currently when the 'About' and 'User Guide' items are clicked on the relevant views are animated onto the screen via a translational transition from the bottom to the top of the screen.

This animation could be altered to a slightly more intuitive right to left translational transition and dismissed via left to right transitions.

If this animation were enabled the views could possibly then be setup so that they could also be dismissed via swiping them to the right.

Many items on the storyboard have never been renamed, this has resulted in one instance of a view controller with about 15 views called "view" which obviously isn't ideal. Would help future maintenance/development if items were given suitable names

Right now when results are updated due to sub-grid changes, the results are animated as changed on the main tab views before the enlarged sub-grid views are fully dismissed.

The app would appear more responsive and actually show the user that the result is changing if this animation was delayed until the view fully appeared.

Should be as simple as updating the results, holding the animation if it came from a sub-view, then checking on 'ViewDidAppear' if the results are different to the ones currently displayed. If so animate

@JamesLongman: 👋 thanks for this app. It was recommended to me by a few people, but I don't see it on the iOS store anymore. Is it under active development still by chance?

A user guide needs to be created for the app and included in the user guide view under the "more" tab.

This should be one of the last tasks done before the beta version otherwise the guide and sample images contained in it may quickly become out of date

Right now the calculator tab results can only be updated by editing ending in its fields. It would be preferable if the results also updating on the view appearing so if the target is changed in another tab it updates upon switching back to the calculator tab

Reported by Askatykus through an app store review.

The bug was when the mortar and target were on either side of the 9-10 divide (for example A9, A10. Or B9, B10) this would cause an error in the distance calculation caused by an error in how double-digit numbers were handled. Basically, the second digit overrode the calculation rather than adding to the sum. This was a one-line fix in 4 separate files and has been hotfixed directly to master

Just noticed on the project's app store page the iPad screenshot was from an old build where constraints were not set up correctly causing fields to touch. Will update the screenshot in the next update to show the correct screenshot without the error

There are several sub-views in the storyboard the sole purpose of which is to directly mirror their parent view in their view controller. They exist solely as a consequence of copy pasting and pose no issue in terms of code nor layout.

Removing them however requires moving all of their contents to the parent view and resetting the constraints. This is an extremely low priority issue due to its time intensive nature and the fact they pose no problem.

Thus far the art assets that the project has been using are placeholders. Artwork needs to be created for the loading screens, tab bars, and app icon and included in assets.xcassets in the appropriate sizes

Having used the corrections tab I find myself questioning why I placed the add field to the left of the subtract field. I personally think I would find it more intuitive on the right so will switch them in the next update

The app should have custom keyboards particularly for the second input fields where there is only a number input needed.

There is the option to include a number only keyboard but the numbers are laid out like a phone (upside down from numpad layout) so I thought that it would be very confusing.

Currently users can start the barrage interval regardless of if correct input has been provided.

It would be more intuitive to disallow the user from starting the timer and possibly let them know why through the 'midLabel' label. An additional feedback method could be to lightly vibrate the device to make the app seem more responsive to the request

Currently the first responder (keyboard) can be dismissed by touching elsewhere in the view other than the field. The mortar and target fields however are not the only view on the screen and are displayed within their parent views.

Touching the parent views would ideally dismiss the first responder

Similar to #12 it would assist future development if a comments pass was made on project files as until now most files have been frequently changing as core features have been developed

There can be a lot on the screen changing when the results are updated, particularly on the barrage tab. Adding a animation to the relevant results may help to draw more attention to them.

Should be pretty simple so will probably roll this into the beta version if possible

A tab could be added to the app where a user can place mortar and target positions via interacting with a map.

This would require the ability to zoom and tap on points on the map to mark them as mortar or target points.

Ideally the tab would update and be updated by the traditional calculator input method and function as a stand alone tab if the user wanted to use the map method

While working on #5 adding initial tests for the project I have come across several functions that are not of the form function (input) { code; return result}, instead most of the offending code is of the form function(input) {code; someOtherClassOrObject.resultingAction() }. The lack of return makes testing difficult and often requiring the use of stubs. Upon a quick search I haven't found any source that simply explains stubbing in swift so for now I am going to add all code requiring tests through this method here.

It would be possible and indeed easier to test a lot of these functions by returning and I have done this in the past whilst writing tests for a node project; but performance is a huge concern with an IOS project and compromising performance would go against the very reason for introducing tests in the first place which is to help ensure a better final project.

This issue will remain open until either tests are added or points can be proved untestable (personally I think this is unlikely) but this is low priority

Currently tracked files marked with TODOs where tests are needed, search project for #35 to find comments

So far a lot of the constraints in the project have been temporary whilst I have been developing the core features. Now that they are mostly in place the constraints require a pass to allow clean consistent presentation across devices ready for the beta version

On a smaller width screen setting the sliders on the barrage tab to any value in particular is a challenge.

The slider would be easier to use if it snapped to the nearest 5m/5seconds for example. This issue would also be a good opportunity to change the defaults to 25m and 25s. 10s proved too fast in testing for an inexperienced team even when alternating between mortars.

After the constraints were updated in #8, xcode terminal now appears to be showing huge error messages upon views loading stating that some constraints cannot be complied to.

Layout seems fine and tracking down the particular constraints causing this will probably be a big job so I'm happy to leave this issue open for the release version and possibly fix this in a later patch

Terminal output: https://pastebin.com/kXS2ipU1

Not really sure exactly what the bug is but at greater radii the target seems to fluctuate wildly to the point where the azumath can do full 360s. If I had to guess I'd say the calculation for the range of y positions is incorrect after the x is chosen.

Not really happy with how the results are currently being presented. There is definately room for improvement in the UI, not really sure how I would like to change the presentation but worth looking into at some point maybe after core features are all complete

The project thus far has conformed to no style guide whatsoever. As I am hoping to add project tests in the next update it would also make sense to conform to a style guide at the same time. A tool I have worked with in the past to automate some aspects of code review is Codacy which seems to be able to assist in conforming to a style guide into a CI solution.

I have never written swift code prior to this project so updating the project will probably require amendments to all project files

Pretty subtle so I didn't notice before but it appears the animation always completes a second or two before the timer does. Will definitely need to fix something this bad before V1

When the user taps on the sub-grid container view in the coordinate input sections the container view transitions to a fullscreen version in its own custom view so that the User will be allowed greater positional resolution.

The transition is currently a simple animation where a full screen version transforms onto the screen from bellow the view. However it would look better and be more intuitive if the container view that was touched simply expanded to a fullscreen version.

This may or may not require a custom animation

Right now tabs can only be changed via touching the tabs icon in the tab bar. Should be possible to also enable swiping.

Not sure if this would present a challenge as it might initialise a separate instance of the views which obviously wouldn't be ideal. Hopefully something like presentView() would be enough

Unfortunately calculators are not perfect and there will always be a degree of error due to estimations made in user input, and at greater ranges large altitude differences can cause errors in calculation due to mortars reaching their targets and less steep angles (An issue impossible to resolve without accurate 3D mapping).

For this reason a 'Corrections' tab may prove useful where the user can provide corrections to the initial calculation if needed; such as adding or subtracting a certain distance to range, or moving the target a certain distance in any direction.

Some time after the project is initially completed it would be nice if tests could be added and some form of CI software such as Travis could be integrated with the repo to assist in any further development that may take place

At the moment the calculations of mortar to target calibrations assume a 2d plane, unfortunately that is rarely the case and height differences can cause an error in the calculation (small at all but extreme ranges and height differences).

This issue is difficult to tackle as it requires accurate 3D mapping of squad maps and a redesigned equation that presumably would be based around parabolic mathematics rather than the current polynomial interpolation the project uses.

I know this is one of the top requested community features of calculators, so even though I am confident the improvement in accuracy will be very small in 95%+ of cases it is a very important issue.

Endebert seems to have made some good progress on this problem for his in-browser map based calculator (as far as I know no community calculators currently account for this).
Endebert/squadmc#4

It would be well worth keeping an eye on this issue to see how he gets on and possibly work on a port if successful.