Programing

여러 JFrame 사용 : 우수 또는 우수 사례?

lottogame 2020. 2. 11. 22:20
반응형

여러 JFrame 사용 : 우수 또는 우수 사례? [닫은]


이미지를 표시하고 데이터베이스에서 소리를 재생하는 응용 프로그램을 개발 중입니다. GUI에서 데이터베이스에 이미지를 추가하기 위해 별도의 JFrame을 사용할지 여부를 결정하려고합니다.

여러 JFrame 창을 사용하는 것이 좋은지 궁금합니다.


여러 JFrame을 사용하는 것이 좋은 방법인지 궁금합니다.

나쁜 (나쁜, 나쁜) 연습.

  • 사용자에게 친숙하지 않음 : 사용자에게는 하나만 표시 될 때 작업 표시 줄에 여러 개의 아이콘이 표시됩니다. 또한 코딩 문제의 부작용 ..
  • 코딩하고 유지해야하는 악몽 :
    • 모달 대화는 그 대화의 내용에 대한 이벤트 초점주의에 쉽게 기회를 - 선택 / 수정 /이를 취소 한 후 진행합니다. 여러 프레임은 그렇지 않습니다.
    • 부모를 클릭하면 부모가있는 대화 상자 (또는 떠 다니는 도구 모음)가 맨 앞에 나타납니다. 원하는 동작 인 경우 프레임으로 구현해야합니다.

하나의 GUI에 많은 요소를 표시하는 방법에는 여러 가지가 있습니다.

  • CardLayout(짧은 데모. ). 좋은:
    1. 대화 상자와 같은 마법사 표시
    2. 연관된 컴포넌트가있는 항목에 대한 목록, 트리 등 선택 사항 표시
    3. 구성 요소가없는 것과 보이는 구성 요소 사이를 뒤집습니다.
  • JInternalFrame/ JDesktopPaneMDI에 일반적으로 사용됩니다 .
  • JTabbedPane 구성 요소 그룹 용.
  • JSplitPane 하나 또는 다른 것 사이의 중요도 (크기)가 두 가지 구성 요소를 표시하는 방법은 사용자의 활동에 따라 다릅니다.
  • JLayeredPane 훨씬 많은 ..layered 구성 요소.
  • JToolBar일반적으로 동작 또는 제어 그룹이 포함됩니다. GUI 주위를 드래그하거나 사용자 요구에 따라 완전히 끌 수 있습니다. 위에서 언급했듯이 부모에 따라 최소화 / 복원합니다.
  • 의 항목으로 JList(아래 간단한 예).
  • 의 노드로 JTree.
  • 중첩 레이아웃 .

그러나 이러한 전략이 특정 사용 사례에서 작동하지 않으면 다음을 시도하십시오. 단일 main JFrame을 설정 한 다음 프레임을 대화 상자의 부모로 사용하여 나머지 자유 부동 요소에 대해 JDialog또는 JOptionPane인스턴스가 표시되도록합니다.

많은 이미지

여러 요소가 이미지 인 경우 대신 다음 중 하나를 사용하는 것이 좋습니다.

  1. JLabel그 순간에 사용자가 관심있는 이미지를 표시 하는 단일 (스크롤 창 중앙). 에서 볼 수 있듯이 ImageViewer.
  2. 단일 행 JList. 이 답변 에서 볼 수 있듯이 . 그 '단일 행'부분은 모두 같은 치수 인 경우에만 작동합니다. 또는 이미지를 즉석에서 스케일링 할 준비가되어 있고 모두 동일한 종횡비 (예 : 4 : 3 또는 16 : 9) 인 경우.


다중 JFrame접근 방식은 Swing 앱 프로그래밍을 시작한 이래 구현 한 것입니다. 대부분, 나는 더 잘 몰랐기 때문에 처음에 해냈습니다. 그러나 개발자로서의 경험과 지식이 성숙하고 훨씬 더 많은 Java 개발자의 의견을 온라인에서 읽고 흡수하기 시작 하면서 현재 프로젝트 및 향후 프로젝트 모두에서 다중 접근 방식 에서 벗어나 려고 JFrame했습니다. )만이 ... 내 고객으로부터 저항을 얻을 ! JInternalFrame별도의 구성 요소에 대한 "자식"창과 s 를 제어하기위한 모달 대화 상자를 구현 하기 시작하면서 고객이 불평하기 시작했습니다!내가 최선의 방법이라고 생각한 것을하고 있었기 때문에 나는 매우 놀랐다! 그러나 그들이 말하는 것처럼 "행복한 아내는 행복한 삶입니다." 고객도 마찬가지입니다. 물론, 계약자이므로 최종 사용자가 개발자 인 본인에게 직접 액세스 할 수 있습니다. 이는 일반적인 시나리오가 아닙니다.

그래서 저는 다중 JFrame접근 방식 의 장점과 다른 사람들이 제시 한 단점을 신화 적 으로 설명 할 것 입니다.

  1. JFrame뛰어난 레이아웃 유연성 -별도의을 허용함으로써 최종 사용자가 자신의 화면에있는 내용을 분산시키고 제어 할 수 있습니다. 이 개념은 "개방적"이고 비 제한적입니다. 당신은 하나의 큰 JFrame무리 로 갈 때 이것을 잃습니다 JInternalFrame.
  2. 매우 모듈화 된 응용 프로그램에 적합 -제 경우에는 대부분의 응용 프로그램이 서로간에 전혀 관련이없는 3-5 개의 큰 "모듈"을 가지고 있습니다. 예를 들어 하나의 모듈은 영업 대시 보드이고 다른 하나는 회계 대시 보드 일 수 있습니다. 그들은 서로 또는 아무 말도하지 않습니다. 그러나 경영자는 두 가지를 모두 열어야 할 수도 있고 작업 표시 줄의 별도 프레임으로 인해 삶을 더 쉽게 만들 수 있습니다.
  3. 최종 사용자가 외부 자료를 쉽게 참조 할 수 있도록합니다 .-일단 다음 상황이 발생했습니다. 내 앱에 "데이터 뷰어"가있어 "새로 추가"를 클릭하면 데이터 입력 화면이 열립니다. 처음에는 둘 다 JFrames였습니다. 그러나 데이터 입력 화면 JDialog이 부모가 데이터 뷰어 인 사람이 되길 원했습니다 . 나는 변화를 만들어, 즉시 나는 그가 최소화하거나 닫을 수 있다는 사실에 크게 의존 최종 사용자로부터 전화 접수 뷰어 및 유지 편집기를 그가 프로그램의 다른 부분 (또는 웹 사이트, 나는 돈을 참조하면서 오픈 기억하지 마십시오). 그는입니다 하지 그가 제 할 항목 대화 상자를 필요로하므로, 다중 모니터에 뭔가 다른데이터 뷰어가 완전히 숨겨져 있습니다. 이것은 불가능 JDialog했으며 확실히 불가능 JInternalFrame했을 것입니다. 나는 JFrames그의 정신 을 위해 분리 된 것으로 다시 바꿨지 만, 그것은 중요한 교훈을 가르쳐 주었다.
  4. 오해 : 코딩하기 어려움-이것은 내 경험에 해당되지 않습니다. 만들 수있는 쉬울 것 왜 표시되지 않습니다 JInternalFrame(A)보다를 JFrame. 사실, 내 경험상 JInternalFrames훨씬 적은 유연성을 제공합니다. 나는 JFrame실제로 잘 작동하는 앱에서 s 의 열기 및 닫기를 처리하는 체계적인 방법을 개발했습니다 . 프레임 코드 자체에서 프레임을 거의 완벽하게 제어합니다. 새로운 프레임의 생성, SwingWorker사용자 시도가 내 열어야 등, 두 번 모두를 엽니 경우 전면 프레임을 가져 / 복원, 해당 컨트롤을 배경 스레드와 EDT의 GUI 코드의 데이터 검색을이야 JFrame들입니다 공개 정적 메소드 open()와 공개 메소드를windowClosing() 이벤트가 나머지를 처리합니다 (프레임이 이미 열려 있습니까? 열려 있지는 않지만로드합니까? 등).이 접근법을 템플릿으로 만들었으므로 각 프레임에 대해 구현하기가 어렵지 않습니다.
  5. 오해 / 증명되지 않은 : 리소스가 많이 소모 됨 -이 추측에 대한 몇 가지 사실을 알고 싶습니다. 비록 100 를 열어도 JFrame더 많은 공간이 필요 하다고 말할 수는 있지만 실제로 얼마나 많은 리소스를 소비하고 있습니까? 리소스 때문에 메모리 누수가 우려되는 경우 : 호출 하면 가비지 수집을 위해 프레임에서 사용하는 모든 리소스가 해제됩니다 (다시 말하면 정확히 동일한 우려를 불러야합니다).JInternalFrameJFramedispose()JInternalFrame

많이 썼는데 더 쓸 수있을 것 같아요. 어쨌든, 나는 그것이 인기가없는 의견이기 때문에 단순히 투표를받지 않기를 바랍니다. 질문은 분명히 귀중한 것이며 일반적인 의견이 아닌 경우에도 귀중한 답변을 제공했으면합니다.

다중 프레임 / SDI 당 단일 문서 ( SDI ) 대 단일 프레임 / 프레임 당 다중 문서 ( MDI )의 좋은 예는 Microsoft Excel입니다. 일부 MDI 혜택 :

  • 직사각형이 아닌 몇 개의 창을 가질 수 있으므로 다른 프로세스 (예 : 웹 브라우저)에서 데스크탑 또는 다른 창을 숨기지 않습니다.
  • 두 번째 Excel 창에서 쓰는 동안 하나의 Excel 창에서 다른 프로세스의 창을 열 수 있습니다. MDI를 사용하면 내부 창 중 하나에 쓰려고하면 전체 Excel 창에 포커스가 생겨 다른 프로세스에서 창을 숨길 수 있습니다
  • 화면마다 다른 문서를 가질 수 있으며, 화면의 해상도가 같지 않을 때 특히 유용합니다

SDI (단일 문서 인터페이스, 즉 모든 창에는 단일 문서 만있을 수 있음) :

여기에 이미지 설명을 입력하십시오

MDI (여러 문서 인터페이스, 즉 모든 창에 여러 문서가있을 수 있음) :

여기에 이미지 설명을 입력하십시오


방금 관련된 예제와 함께 "사용자 친화적이지 않은"논증에 반대하고 싶습니다.

우리의 응용 프로그램에는 사용자가 별도의 탭으로 다양한 '프로그램'을 실행하는 기본 창이 있습니다. 우리는 가능한 한이 응용 프로그램을이 단일 창에 유지하려고 노력했습니다.

One of the 'programs' they run presents a list of reports that have been generated by the system, and the user can click on an icon on each line to pop open a report viewer dialog. This viewer is showing the equivalent of the portrait/landscape A4 page(s) of the report, so the users like this window to be quite big, almost filling their screens.

A few months ago we started getting requests from our customers to make these report viewer windows modeless, so that they could have multiple reports open at the same time.

For some time I resisted this request as I did not think this was a good solution. However, my mind was changed when I found out how the users were getting around this 'deficiency' of our system.

They were opening a viewer, using the 'Save As' facility to save the report as a PDF to a specific directory, using Acrobat Reader to open the PDF file, and then they would do the same with the next report. They would have multiple Acrobat Readers running with the various report outputs that they wanted to look at.

So I relented and made the viewer modeless. This means that each viewer has a task-bar icon.

When the latest version was released to them last week, the overwhelming response from them is that they LOVE it. It's been one of our most popular recent enhancements to the system.

So you go ahead and tell your users that what they want is bad, but ultimately it won't do you any favours.

SOME NOTES:

  • It seems to be best practice to use JDialog's for these modeless windows
  • Use the constructors that use the new ModalityType rather than the boolean modal argument. This is what gives these dialogs the task-bar icon.
  • For modeless dialogs, pass a null parent to the constructor, but locate them relative to their 'parent' window.
  • Version 6 of Java on Windows has a bug which means that your main window can become 'always on top' without you telling it. Upgrade to version 7 to fix this

Make an jInternalFrame into main frame and make it invisible. Then you can use it for further events.

jInternalFrame.setSize(300,150);
jInternalFrame.setVisible(true);

It's been a while since the last time i touch swing but in general is a bad practice to do this. Some of the main disadvantages that comes to mind:

  • It's more expensive: you will have to allocate way more resources to draw a JFrame that other kind of window container, such as Dialog or JInternalFrame.

  • Not user friendly: It is not easy to navigate into a bunch of JFrame stuck together, it will look like your application is a set of applications inconsistent and poorly design.

  • It's easy to use JInternalFrame This is kind of retorical, now it's way easier and other people smarter ( or with more spare time) than us have already think through the Desktop and JInternalFrame pattern, so I would recommend to use it.


Bad practice definitely. One reason is that it is not very 'user-friendly' for the fact that every JFrame shows a new taskbar icon. Controlling multiple JFrames will have you ripping your hair out.

Personally, I would use ONE JFrame for your kind of application. Methods of displaying multiple things is up to you, there are many. Canvases, JInternalFrame, CardLayout, even JPanels possibly.

Multiple JFrame objects = Pain, trouble, and problems.


I think using multiple Jframes is not a good idea.

Instead we can use JPanels more than one or more JPanel in the same JFrame.

Also we can switch between this JPanels. So it gives us freedom to display more than on thing in the JFrame.

For each JPanel we can design different things and all this JPanel can be displayed on the single JFrameone at a time.

To switch between this JPanels use JMenuBar with JMenuItems for each JPanelor 'JButtonfor eachJPanel`.

More than one JFrame is not a good practice, but there is nothing wrong if we want more than one JFrame.

But its better to change one JFrame for our different needs rather than having multiple JFrames.


If the frames are going to be the same size, why not create the frame and pass the frame then as a reference to it instead.

When you have passed the frame you can then decide how to populate it. It would be like having a method for calculating the average of a set of figures. Would you create the method over and over again?


좋은 방법은 아니지만 사용하려는 경우에도 싱글 톤 패턴을 좋은 것으로 사용할 수 있습니다. 나는 대부분의 프로젝트에서 싱글 톤 패턴을 사용했다.

참고 URL : https://stackoverflow.com/questions/9554636/the-use-of-multiple-jframes-good-or-bad-practice



반응형