I'm working on a bookshelf project. I'm still new to programming, but i managed to make the Google Books API work so far, but when I receive the search results, my side drawer (side menu) doesn't expand.
Also, if I want to make a "load more results", what would be the best approach?
Video of the problem: https://www.loom.com/share/12ab331cf37f41038f6da294f5e5ea29
Vercel: https://academicshelf.vercel.app/discover
Best regards,
Frederik
So rather than "expanding" the side bar, make it's height: 100vh and position: fixed. That way, as the user scrolls, the side bar scrolls with them.
As for the "load more results" bit, this is dependent upon your implementation. You're either going to want to paginate or do "infinite scrolling". Pagination can take on the look of a bar at the bottom with total results and different pages, or a simplified version of it would literally just add an element to the bottom that says "load more..." and will load the next set of elements by expanding upon the current list. This prevents the client from downloading a lot of content for items they will never see. For performance, I would recommend lazily loading the next set of results so that when the user clicks the button, it loads the next set instantaneously.
Related
The following question is about RichTexFX. For standard JavaFX components, I've never had this issue before.
In my application, I am adding text content to the end of a GenericStyledArea (actually a subclass of it, but that should have no impact on the behaviour I am observing). Every time new content has been added to the end of the document, I scroll to the bottom so the new content is always in view. I use the following code to scroll to bottom (actually written in Kotlin, but I have translated it to Java below):
showParagraphAtTop(document.getParagraphs().size() - 1)
This almost always works. However, in some cases the screen will not show the newly added element. I have come to the conclusion that by the time showParagraphAtTop is called, some internal state in richtextfx has not been updated. This is because I added a button that I can click on to call the code above, and if I click it after the scroll failed, it scrolls to the bottom as expected.
I have tried various ways to work around this, but the only solution that works reliably is to do the following:
FxTimer.runLater(Duration.ofMillis(10), () -> showParagraphAtTop(getDocument().getParagraphs().size() - 1));
In other words, I force a short delay before actually scrolling the screen.
Even though the above works, it's incredibly unsatisfactory, and there should be some way to do this the right way. However, I have been unable to figure it out.
I saw another question (Autoscroll JavaFX TextFlow) which suggested the use of layout() prior to scrolling. This does not remove the problem, although it does appear to make it less common.
I'm rendering a video progress bar with the following:
<div class="video-timeline">
{{#isolate}}
<div style="width: {{progressBarWidth}}" class="video-progress-bar"></div>
{{/isolate}}
</div>
The progress bar fits inside the timeline and extends to the right as the video's time advances (based on a session variable). The goal is to observe clicks on the timeline so I can change the play location.
Click events on the timeline to the right of the progress bar are observed correctly. However, while the video is playing (and the progress bar is being continually rendered) a click on the progress bar itself will infrequently bubble up to the timeline click handler.
How can I observe these events, or is there a better way to do this altogether?
Update: Using an overlay (as suggested by datacarl) is probably best if you absolutely need to have an element which is updated multiple times a second and controlled by meteor. This worked for me but, I ended up reverting to a jQuery-based solution for that particular part of the template. As much as I dislike mixing jQuery events and meteor events, jQuery was provided a more responsive and less error-prone way to update the progress bar.
I think the simplest way to handle this is to absolute position a div.progress-bar-overlay on top of div.video-progress-bar and observe the clicks on .progress-bar-overlay instead. Give it the same height and width as .video-timeline. That way you do not have to handle whether the user clicks on the .video-timeline or on the .video-progress-bar.
Short Version:
"How do you get a simple UITable drill down UINavigationController-styled non-full-screen modal dialog on the iPad?"
Long version:
I have a very specific set of requirements that I can't seem to get working...
I have a functioning iPad program that that needs to pop up a non-full-screen modal view. This modal needs to have a navigation controller and a simple drill-down table that displays a detailed view that I can have edit some values related to the selected item in the table.
Of course I am looking to have the regular "Back" and "Delete" buttons in the Navigation Bar.
I can handle the detailed view, what I am having issues with:
Non-full-screen popup (mine is
always full screen no matter what I
try).
The Navigation controller will not display the Table View I tell it to and the navigation bar does not even have the title I assigned to it in IB.
I can't seem to get any of this working. If anyone has a step by step example of how to do this, that would be great,
~Eric
P.S. I am not afraid of doing this 100% programmatically, but all the examples I have been trying to follow (and failing at extending to my problem) use IB.
As for the fullscreen issue, you need to set modalPresentationStyle to UIModalPresentationFormSheet or UIModalPresentationPageSheet on the controller you want to present modally. I'm not sure of a way to do this through IB.
As for your navigation controller/table view, I think more information is needed to provide an answer.
I have a single web page with master detail form/input layout. Currently the form works in a way like
User opens the page containing both master/detail data entry controls and enters the master information (The details save button is disabled)
When he saves the master information, the save master button gets disabled and save details is enabled
User continues to enter multiple details which get populated in a gridview at the bottom of page
All works well
Problem is that, the master part contains a lot of data entry controls (drop down lists gridviews etc)
How do I facilitate the user much more then the current layout? Should he be redirected to a new page after he enters the master record ? How can I improve on this?
If the user doesn’t need to refer to the entire master to complete the detail, and isn’t navigating among multiple masters to view/edit their details, then you don’t need a master-detail, and you can divide the input into two or more windows. A window for the details can repeat a few fields from the master that users need to complete the details.
Assuming it is desirable to keep everything on the same page, I think I see few things you can do:
Use edit-in-place for both the master and detail, so you don’t need space for both editing/creating a record and space to display it. Every field should only appear once.
Pack your controls more tightly together. You can do this without appearing too cluttered if you adopt a quieter visual style (e.g., lose the reverse-video and the rules). Allocate about 20 vertical pixels per single-row control
Adopt an object-selection-action syntax so you don’t need to take space repeating the same command buttons/links for every record. That leaves mores space for fields.
Put your tables in their own panes with vertical scrolling. The tables you have now are already pretty short (5 or fewer rows), but limiting them to 5 or fewer visible rows will keep the window from being too long for cases when there are a lot of rows.
Assuming you have edit-in-place, use wider tables, each set in their own pane with horizontal scrolling in order to reduce the height by moving fields out of the “overflow” spaces and into the tables. Be sure you have row headers that do not scroll away.
Divide fields up into tabs, especially on the master. That reduces the space the master needs to a fraction. You can have tabs within a portion of the master if your users need to keep key fields constantly visible.
Put some fields within the master or detail in expanders or secondary windows, especially for fields the user doesn’t necessary need to interact with (e.g., where usually the default values are correct). Show an aggregate, abbreviation, or summary of what the users don’t see to cue them on when they do need to interact with the fields.
Consider using a “paging” interface for your stack of multi-row text boxes at the bottom of the master so they’re “stacked” in the z-dimension rather than the y-dimension and thus take up the space of a single text box.
Consider using more compact drop-down lists rather than radio buttons, especially for fields the user is less likely to change (e.g., the default is very often correct). A dropdown list is more work to set a value (takes two clicks) but no more to see the value, and you can weigh the editing effort against navigation effort (scrolling, tab-clicking, etc.)
Consider putting the entire master in its own scrolling pane so the detail is always in view at normal window size and the user can scroll the master to whatever portion is relevant for entering details.
If users are telling you that everything in the window must be constantly in view, then you’re going to have to dig deeper, prioritize fields, and make trade-offs because that’s not going to happen unless your client buys everyone a suite of big-ass monitors. Some fields will be out of view, even it that just means scrolled out of view.
There can be various options:
Page may show master and summary (gridview) of details. Save button will only work for master data. Add/Edit details will happening in a modal pop-up.
Have a tabbed view - one tab will show master while other tab will show details. There will be one save button per tab. Tab switching will happen on client side.
Have both master and details always open for editing. Any changes in details will be temporarily held in view-state/session-state. The save button for master will save changes for both master and details. No need to disable any UI.
We typically prefer #1 - IMO, its simple UI from user's perspective.
I have a bit of doubt regarding my application which is being created using Mate framework. The first thing user has to do is to log in, so I created Login.mxml view. After a successful login I need to display the main view with applicationControlBar at the top and a workspace below. At the moment I have two separate views, so if I understand correctly it makes sense using ViewStack.
Thing is, I'd like also to display some kind of panel with buttons on top of the workspace after login - here is screenshot. After clicking on a button the panel should dissapear. To complicate things a little bit more, there is a possibility for this panel to change state. Clicking on a specific button may result in showing progress bar at the bottom of panel.
I feel I should create separate view, MenuDialog.mxml and put there buttons, progress bar and states, but how to display it on the top of the workspace? I hope my problem is clear enough :)
I would make the panel a popUp, with the main application (or the ViewStack's parent container) as the parent of the popUp. You can use the PopUpManager Class to close it based on user actions within the Panel.
Assuming that perhaps you do not want a modal login style panel (which many apps these days eschew) then you should absolutely use states rather than ViewStacks.
States are a much cleaner way to distinguish the various, uh, states that your UI can be in -LOGGED_IN, LOGGED_OUT, etc.
It may take a little to get used to working with states, but once you do, you'll never go back. :-)